rabbitmq-queues, HTTP API: consider providing a way to force a QQ to take a checkpoint

[michaelklishin]

Is your feature request related to a problem? Please describe.

Due to how quorum queue reclaims its disk space — by deleting segment files that have no live [1] when certain client-driven events happen — a QQ can accumulate a decent disk space footprint.
Under continuous operations where consumers and thus the QQ make progress, this only requires a certain amount of (overprovisioned) disk space.

However, when publishers, consumers and the queue itself go completely quiet after a period of very
high activity with large messages, the segment file truncation won't happen. This scenario is common
for data processing pipelines where activity can be intense but intermittent.

Describe the solution you'd like

For such scenarios, there are two ways to quickly reclaim disk space:

1. Purge the queue (if it's empty)
2. Force a checkpoint using ra:cast_aux_command(ServerId, force_checkpoint).

Perhaps the 2nd option could be wrapper in a CLI command. Assuming we do not find an "automatic" way for QQs to do this, which is a lot less obvious because detecting a period of inactivity is prone to false positives.

1. Ready for delivery or delivered and pending consumer acknowledgement

[aaron-seo]

This is something that we'd be interested in and have discussed in the past as well. I have a rough working implementation: the idea is to write wrapper functions over ra:cast_aux_command(ServerId, force_checkpoint) in the rabbit_quorum_queues module and that should be make it easy to cleanly wrap it again in a CLI command, which seems to be a common pattern so far.

If someone has a good heuristic for an "automatic" way, it could also be reused for that.

[michaelklishin]

@aaron-seo yes, that's roughly what I have in mind.