Always use Lsn::MAX as the request LSN in the primary

[hlinnaka]

The new protocol version supports sending two LSNs to the pageserver:
request LSN and a "not_modified_since" hint. A primary always wants to
read the latest version of each page, so having two values was not
strictly necessary, and the old protocol worked fine with just the
"not_modified_since" LSN and a flag to request the latest page
version. Nevertheless, it seemed like a good idea to set the request
LSN to the current insert/flush LSN, because that's logically the page
version that the primary wants to read.

However, that made the test_gc_aggressive test case flaky. When the
primary requests a page with the last inserted or flushed LSN, it's
possible that by the time that the pageserver processes the request,
more WAL has been generated by other processes in the compute and
already digested by the pageserver. Furthermore, if the PITR horizon
in the pageserver is set to 0, and GC runs during that window, it's
possible that the GC horizon has advances past the request LSN, before
the pageserver processes the request. It is still correct to send the
latest page version in that case, because the compute either has the
page locked so the it cannot have been modified in the primary, or if
it's a prefetch request, and we will validate the LSNs when the
prefetch response is processed and discard it if the page has been
modified. But the pageserver doesn't know that and rightly complains.

To fix, modify the compute so that the primary always uses Lsn::MAX in
the requests. This reverts the primary's behavior to how the protocol
version 1 worked. In protocol version 1, there was only one LSN, the
"not_modified_since" hint, and a flag was set to read the latest page
version, whatever that might be. Requests from computes that are still
using protocol version 1 were already mapped to Lsn::MAX in the
pageserver, now we do the same with protocol version 2 for primary's
requests. (I'm a bit sad about losing the information in the
pageserver, what the last LSN was at the time that the request wa
made. We never had it with protocol version 1, but I wanted to make it
available for debugging purposes.)

Add another field, 'effective_request_lsn', to track what the flush
LSN was when the request was made. It's not sent to the pageserver,
Lsn::MAX is now used as the request LSN, but it's still needed
internally in the compute to track the validity of prefetch requests.

Fixes issue #7692

Review note

This PR consists of two commits: the first one is a mechanical refactoring, while the second commit contains the fix. I recommend reviewing them separately, to see what's going on.

[github-actions]

3060 tests run: 2927 passed, 0 failed, 133 skipped (full report)

---

Flaky tests (1)

Postgres 15

• test_pageserver_init_node_id: release

Code coverage* (full report)

• functions: 31.4% (6329 of 20161 functions)
• lines: 47.3% (47748 of 100970 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
b3cb64e at 2024-05-13T11:03:51.685Z :recycle:}

[koivunej]

Failures on Postgres 16

• test_ancestor_detach_branched_from[False-True-after]: debug

This is a shutdown problem just producing a more gnarly error with validated get_vectored fixed in #7716.

Failures on Postgres 15

• test_partial_evict_tenant[relative_equal]: release

I'll add this to #7536.