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.

Open questions:

• do we want the header? I assumed no because I didn't want to implement the CRC32 sink but I implemented it anyway, so it could be stored, but I don't see how useful would this be.

[github-actions]

3024 tests run: 2891 passed, 0 failed, 133 skipped (full report)

---

Flaky tests (2)

Postgres 16

• test_gc_aggressive: debug

Postgres 14

• test_timeline_size_quota_on_startup: release

Code coverage* (full report)

• functions: 31.5% (6345 of 20171 functions)
• lines: 47.3% (47757 of 100885 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
6970bde at 2024-05-10T12:44:43.316Z :recycle:}