QQ: Revise checkpointing logic to take more frequent checkpoints for large message workloads

[kjnilsson]

Lower the min_checkpoint_interval substantially to allow quorum queues better control over when checkpoints are taken.

Tracking message bytes written to the log and use this to request a checkpoint every 64MB if no other checkpoint condition was met. This ensures that queues where the messages are very large (1MB+) are checkpointed based on their data ingress rather than indexes.

[kjnilsson]

Testing:

Try various workloads with both small and large messages and monitor the disk to ensure that there is no undue segment buildup that is retained when workload is paused.

Also ensure segments are cleared up reasonably after queue is emptied / purged.

For large message workloads this PR works best with a lower raft.segment_max_entries configuration, for example 64. This is until we can include rabbitmq/ra#526 which will put an upper byte size limit on segments (in addition to the entry based limit which is 4096 by default)

[mkuratczyk]

We've run lots of tests with different variations of the tweaks. This clearly improves the situation with many slow queues, especially as messages get larger. In this test, all queues are empty (publishers are slow and consumers are present so they immediately get the messages). We can see that main uses more and more disk space, while this branch does not.