pageserver: change pitr_interval=0 behavior

[jcsp]

Problem

We already made a change in #6407 to make pitr_interval authoritative for synthetic size calculations (do not charge users for data retained due to gc_horizon), but that change didn't cover the case where someone entirely disables time-based retention by setting pitr_interval=0

Relates to: #6374

Summary of changes

When pitr_interval is zero, do not set pitr_cutoff based on gc_horizon.

gc_horizon is still enforced, but separately (its value is passed separately, there was never a need to claim pitr_cutoff to gc_horizon)

More detail

Issue 1

Before this PR, we would skip the update_gc_info for timelines with last_record_lsn() < gc_horizon.
Let's call such timelines "tiny".

The rationale for that presumably was that we can't GC anything in the tiny timelines, why bother to call update_gc_info().

However, synthetic size calculation relies on up-to-date update_gc_info() data.

Before this PR, tiny timelines would never get an updated GcInfo::pitr_horizon (it remained Lsn(0)).
Even on projects with pitr_interval=0d.

With this PR, update_gc_info is always called, hence GcInfo::pitr_horizon is always updated, thereby
providing synthetic size calculation with up-to-data data.

Issue 2

Before this PR, regardless of whether the timeline is "tiny" or not, GcInfo::pitr_horizon was clamped to at least last_record_lsn - gc_horizon, even if the pitr window in terms of LSN range was shorter (=less than) the gc_horizon.

With this PR, that clamping is removed, so, for pitr_interval=0, the pitr_horizon = last_record_lsn.

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]

2772 tests run: 2654 passed, 0 failed, 118 skipped (full report)

---

Code coverage* (full report)

• functions: 28.1% (6466 of 23041 functions)
• lines: 46.8% (45688 of 97596 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
a0e68ce at 2024-04-23T08:55:24.394Z :recycle:}

[problame]

I think this PR fixes two orthogonal issues in one go.
Please confirm my understanding.
Might be worth pointing out in the commit message for future readers.

Issue 1

Before this PR, we would skip the update_gc_info for timelines with last_record_lsn() < gc_horizon.
Let's call such timelines "tiny".

The rationale for that presumably was that we can't GC anything in the tiny timelines, why bother to call update_gc_info().

However, synthetic size calculation relies on up-to-date update_gc_info() data.

Before this PR, tiny timelines would never get an updated GcInfo::pitr_horizon (it remained Lsn(0)).
Even on projects with pitr_interval=0d.

With this PR, update_gc_info is always called, hence GcInfo::pitr_horizon is always updated, thereby
providing synthetic size calculation with up-to-data data.

Issue 2

Before this PR, regardless of whether the timeline is "tiny" or not, GcInfo::pitr_horizon was clamped to at least last_record_lsn - gc_horizon, even if the pitr window in terms of LSN range was shorter (=less than) the gc_horizon.

With this PR, that clamping is removed, so, for pitr_interval=0, the pitr_horizon = last_record_lsn.

[jcsp]

Thanks, yes - that's all accurate. The "Issue 1" part is mainly just to make tests with small data behave, but it's also a valid change for production if a user has a small WAL.

I've copied it into the PR desc.