v2.2: blockstore: Update flaky compaction test (backport of #5131)

[mergify]

Problem

See #4188 for more context, but the TLDR:

• We have a custom compaction filter that deletes data
• We have a unit tests that relies on compaction running & deleting this data
• We have found our unit test is flaky because rocksdb will sometimes no-op when we request a compaction; this is rocksdb functioning as intended but just unfortunate for us. rocksdb was essentially seeing no work to be done in this case

Summary of Changes

Update the compaction call to NOT take start/end keys, which results in the entire column being considered for compaction. This results in a different call path in rocksdb being used which picks up the overlapping data (which signals to run a compaction) every time.

Previously, I could run the failing unit test in a loop and see a failure within ~20 iterations, often times fewer. With this PR, I have run > 500 iterations without failure

This isn't necessarily a perfect solution; however, I think it is a "good enough" solution for now so our team can get back time from flaky CI. RPC will call blockstore functions that check the value of the atomic before proceeding; we could possibly go that route but then this test isn't exercising much more than setting and reading an integer

---

This is an automatic backport of pull request #5131 done by Mergify.

[t-nelson]

@mergify rebase

[mergify]

rebase

☑️ Nothing to do

• any of:
  • #commits > 1 [📌 rebase requirement]
  • #commits-behind > 0 [📌 rebase requirement]
  • -linear-history [📌 rebase requirement]
• -closed [📌 rebase requirement]
• -conflict [📌 rebase requirement]
• queue-position = -1 [📌 rebase requirement]

[steviez]

mergify rebase

Too slow @t-nelson 😉

That force push was simply a rebase, forgot that we can do it with bots. Was going to add you as a reviewer once CI finished, but we're close enough so doing it now