quantification of compaction algorithms

[problame]

Child of 2024Q2 compaction work: https://github.com/neondatabase/neon/issues/8001

This epic tracks the efforts to quantify any compaction algorithm's outcomes.

We had a brainstorming session some time back to come up with an (incomplete) set of potentially useful metrics: https://www.notion.so/neondatabase/Productionize-Tiered-Compaction-eca9b06aa1ae4c62bdf6cf40ab002eb6?pvs=4

Meeting notes / ideas:

• point-in-time efficiency: Use layer map dump / keyspace dump (not actually measure it by access)
• total space efficiency:
  • (logical size + wal in PITR window) = synthetic size, can just use that
  • sum(all layer files in index_part.json) => just that

Demo test case to adapt / apply the Python helpers to:

• test_gc_feedback

### Refs
- [ ] https://github.com/neondatabase/neon/pull/7867
- [ ] develop automated workflow to back-test & perf-evaluate with production data

[problame]

This week:

• extend / follow-up on the pagectl PR #7867 so that it runs the estimations against test_gc_feedback

[problame]

This week, @problame to address his follow-up requests from https://github.com/neondatabase/neon/pull/7867#pullrequestreview-2096797786

[problame]

This issue was part of

• https://github.com/neondatabase/neon/issues/8001

In the end, that work expanded into Q3 and we focussed solely on bottommost compaction.

Bottommost compaction is very deterministic and hence, the existing quantification work in test_gc_feedback (https://github.com/neondatabase/neon/pull/7867) is sufficient to qualify & quantify it.