refactor: remove eviction batching

[koivunej]

We no longer have layer_removal_cs since #5108, we no longer need batching.

[github-actions]

2148 tests run: 2064 passed, 0 failed, 84 skipped (full report)

---

Flaky tests (1)

Postgres 14

• test_pageserver_restarts_under_worload: debug

Code coverage (full report)

• functions: 54.8% (9352 of 17067 functions)
• lines: 82.0% (54280 of 66178 lines)

---

_{The comment gets automatically updated with the latest test results
0b4109b at 2023-12-11T18:17:04.756Z :recycle:}

[problame]

The disk-usage-based eviction batched by timeline.
IIRC one goal behind that was to only update the IndexPart once, instead of on each individual eviction.
I guess we already lost that property when we introduced the struct Layer?

Also, I feel like the per-timeline eviction code could also benefit from the slightly advanced joinset acrobatics you're doing in the disk-usage-based eviction. Not sure if it's easy to extract that into a common function.

If you can't extract it into a common function, please add a comment explaining the acrobatics. My understanding is that it's to limit the number of pending evict_and_wait tasks?

[koivunej]

The disk-usage-based eviction batched by timeline.
IIRC one goal behind that was to only update the IndexPart once, instead of on each individual eviction.
I guess we already lost that property when we introduced the struct Layer?

No. The unlinking has already done at the end of compaction or GC, it was introduced on #5645 perhaps.

one goal behind that was to only update the IndexPart once, instead of on each individual eviction.

I did not remember that, but compaction is still scheduling 1-2 updates even with the inverted l0=>l1 vs. image layer ordering going to prod soon (#5950) and gc schedules one. My motivation for this PR is recently gained absence of layer_removal_cs.

One could say we should have at least one test asserting how many index part updates we do, just in case.

[koivunej]

Noted thing: Layer::evict_and_wait can hang by bug (I am quite sure we've seen zero of such bugs) but anyways there should be a timeout like I envisioned in #4745. I'll add it in a follow-up, added only bonus logging here.... Could actually that in the follow-up as well, so this is almost like a refactoring PR.

Failures on Postgres 14

• test_peer_recovery: debug

This failure looks weird, but not caused by this PR.