feat(pageserver): support key range for manual compaction trigger

[skyzh]

Problem

part of #9114, we want to be able to run partial gc-compaction in tests. In the future, we can also expand this functionality to legacy compaction, so that we can trigger compaction for a specific key range.

Summary of changes

• Support passing compaction key range through pageserver routes.
• Refactor input parameters of compact related function to take the new CompactOptions.
• Add tests for partial compaction. Note that the test may or may not trigger compaction based on GC horizon. We need to improve the test case to ensure things always get below the gc_horizon and the gc-compaction can be triggered.

[github-actions]

5534 tests run: 5308 passed, 0 failed, 226 skipped (full report)

---

Flaky tests (1)

Postgres 17

• test_cli_start_stop: release-arm64

Code coverage* (full report)

• functions: 31.4% (7935 of 25246 functions)
• lines: 49.6% (62994 of 127004 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
681fb1b at 2024-11-19T19:07:40.173Z :recycle:}

[problame]

Occupying the entire request body for just the CompactRange will make it harder to extend the endpoint down the line.

I think it shouldn't be particularly hard/time consuming to move all the query fields (force_l0_compaction, force_repartition etc) into a struct TimelineCompactRequest.

(The reason why it shouldn't be particularly time consuming is that the the only place where we're constructing the request is in the ps_http.timeline_compact() implementation.

Please do bit that bullet here, much appreciated!

Other than that, this looks good. Approving so you can merge this before your weekend starts

[arpad-m]

two minor points

[skyzh]

I think we should move all these compaction configs to the POST body. Given the compaction tests are now the only users for the API, we can change it as much as we want in the future (hopefully, in the next two week? as I'll probably add more options to the API and the current way of doing it is not manageable...)