feat(pageserver): add k-merge layer iterator with lazy loading

[skyzh]

Problem

Part of #8002. This pull request adds a k-merge iterator for bottom-most compaction.

Summary of changes

• Added back lsn_range / key_range in delta layer inner. This was removed due to fix: vectored get returns incorrect result on inexact materialized page cache hit #8050, but added back because iterators need that information to process lazy loading.
• Added lazy-loading k-merge iterator.
• Added iterator wrapper as a unified iterator type for image+delta iterator.

The current status and test should cover the use case for L0 compaction so that the L0 compaction process can bypass page cache and have a fixed amount of memory usage. The next step is to integrate this with the new bottom-most compaction.

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]

3067 tests run: 2952 passed, 0 failed, 115 skipped (full report)

---

Flaky tests (2)

Postgres 16

• test_compaction_induced_by_detaches_in_history: release

Postgres 14

• test_pg_regress[None]: release

Code coverage* (full report)

• functions: 32.7% (6970 of 21322 functions)
• lines: 50.1% (54811 of 109372 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
d9e0e29 at 2024-07-09T20:44:56.287Z :recycle:}

[problame]

Aplogogies for the delayed review!

---

Why aren't we implementing futures::Stream so we can use peekable instead of the home-grown thing added in this PR?

(Not asking for it to happen in this PR, just generally => maybe let's discuss on Slack)

---

Requesting some changes, if you disagree let's discuss on Slack . Re-request review once address.

[skyzh]

Why aren't we implementing futures::Stream so we can use peekable instead of the home-grown thing added in this PR?

I want to avoid using Stream because it introduces opaque type and cannot be stored in other structs.

[problame]

I want to avoid using Stream because it introduces opaque type and cannot be stored in other structs.

What I mean is impl Stream for LayerIter , then by the magic of StreamExt, your LayerIter suddendly has a method peekable() that returns a Peekable<LayerIter>.

No opaque types anywhere.

But, anyway, not asking for it in this PR.