CQ: Make CQ shared store compaction fast

[lhoguin]

This PR does 3 things:

• Don't compact shared message store files too eagerly: if a file is about to be compacted AND is scheduled to be compacted 15s from now, we wait 15s before compacting.
• Restore the use of file scanning instead of ets scanning for finding messages to be compacted, in the file. Ideally this would be a secondary ets key, but we don't have that, so using ets is too slow.
• Rework the file scanning to make sure we never forget a file (as the old 3.12 algorithm does not work well with compaction being a thing) and add many tests for various likely and unlikely scenarios.

Types of Changes

• Bug fix (non-breaking change which fixes issue rabbitmq used disk space grows after upgrade to 3.13 #10681)

[mkuratczyk]

Test results: https://grafana.lionhead.rabbitmq.com/goto/3Bgb8QASR?orgId=1

While there are other differences - some small performance regressions and some improvements, the most important is that there are no more memory spikes like this:

This spikes correlate with the issue #10681 (at least in my testing) since they are a caused by a backlog of compaction requests.

Other notable differences:

1. The publishing throughput is significantly higher when consumers try to catch up on a backlog of messages. Previously they would immediately trigger a lot of compaction, which is now delayed, leaving more resources for publishers (the part of the graph where 3.13/blue drops to almost zero):
   

2. On the other hand, because there's more compaction work performed later, publisher throughput is lower (second part of the graph above).

[lhoguin]

Thank you! Better compaction scheduling is something we can improve at a later time.