feat: support changing IndexPart::metadata_bytes to json in future release

[koivunej]

Problem

Currently we serialize the TimelineMetadata into bytes to put it into index_part.json. This Vec<u8> (hopefully [u8; 512]) representation was chosen because of problems serializing TimelineId and Lsn between different serializers (bincode, json). After #5335, the serialization of those types became serialization format aware or format agnostic.

We've removed the pageserver local metadata file writing in #6769.

Summary of changes

Allow switching from the current serialization format to plain JSON for the legacy TimelineMetadata format in the future by adding a competitive serialization method to the current one (crate::tenant::metadata::modern_serde), which accepts both old bytes and new plain JSON.

The benefits of this are that dumping the index_part.json with pretty printing no longer produces more than 500 lines of output, but after enabling it produces lines only proportional to the layer count, like:

{
  "version": ???,
  "layer_metadata": { ... },
  "disk_consistent_lsn": "0/15FD5D8",
  "legacy_metadata": {
    "disk_consistent_lsn": "0/15FD5D8",
    "prev_record_lsn": "0/15FD5A0",
    "ancestor_timeline": null,
    "ancestor_lsn": "0/0",
    "latest_gc_cutoff_lsn": "0/149FD18",
    "initdb_lsn": "0/149FD18",
    "pg_version": 15
  }
}

This is an alternative to #7663, which still uses the Vec<u8> idea, but this time with mixed bincode+json instead of just bincode.

In the future, I propose we completely stop using this legacy metadata type and wasting time trying to come up with another version numbering scheme in addition to the informative-only one already found in index_part.json, and go ahead with storing metadata or feature flags on the index_part.json itself.

#7699 is the "one release after" changes which starts to produce metadata in the index_part.json as json.

[github-actions]

3186 tests run: 3047 passed, 0 failed, 139 skipped (full report)

---

Flaky tests (2)

Postgres 14

• test_pageserver_restarts_under_worload: release
• test_peer_recovery: debug

Code coverage* (full report)

• functions: 31.5% (6590 of 20918 functions)
• lines: 48.4% (50913 of 105084 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
44d4146 at 2024-06-04T15:23:26.411Z :recycle:}

[koivunej]

We had some discussion perhaps last week if we want to keep the checksum or not in the json. The next PR will include refactoring which makes it trivial to include but, I'd rather not reorder the commits.