feat(pageserver): separate sparse and dense keyspace

[skyzh]

Problem

extracted (and tested) from #7468, part of #7462.

The current codebase assumes the keyspace is dense -- which means that if we have a keyspace of 0x00-0x100, we assume every key (e.g., 0x00, 0x01, 0x02, ...) exists in the storage engine. However, the assumption does not hold any more in metadata keyspace. The metadata keyspace is sparse. It is impossible to do per-key check.

Ideally, we should not have the assumption of dense keyspace at all, but this would incur a lot of refactors. Therefore, we split the keyspaces we have to dense/sparse and handle them differently in the code for now. At some point in the future, we should assume all keyspaces are sparse.

Summary of changes

• Split collect_keyspace to return dense+sparse keyspace.
• Do not allow generating image layers for sparse keyspace (for now -- will fix this next week, we need image layers anyways).
• Generate delta layers for sparse keyspace.
• This pull request includes part of chore(pageserver): shrink aux keyspace to 0x60-0x7F #7502.

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[github-actions]

2850 tests run: 2729 passed, 0 failed, 121 skipped (full report)

---

Flaky tests (2)

Postgres 15

• test_partial_evict_tenant[relative_spare]: release
• test_vm_bit_clear_on_heap_lock: debug

Code coverage* (full report)

• functions: 28.2% (6583 of 23352 functions)
• lines: 47.0% (46825 of 99721 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
32b41bd at 2024-04-29T19:01:40.383Z :recycle:}

[jcsp]

Generally LGTM, I like the concept of using distinct KeySpaces for now.

In an earlier iteration of #6778 , I attempted to replace the inner Range<> type of KeySpace with something smarter that could represent the sparseness of sharding, but it was a rather painful diff, so makes sense that this PR also leaves that existing "dense KeySpace" type as-is.

Ideally, we should not have the assumption of dense keyspace at all

Agree.

[skyzh]

resolved merge conflicts with main, ready for review

resolved