WAL restore: support reading WAL files from a Barman Cloud object-store layout as a fallback (read-only)

[gbartolini]

Problem

When a requested WAL segment isn't found in Klio's native archive, there's currently no way to check whether it exists in a Barman Cloud archive in the same object store, and no way to retrieve it if so. This blocks replay of WAL that predates a cluster's migration to Klio.

Requirements

• Read-only: no write against Barman Cloud objects.
• No dependency on the barman-cloud plugin being installed or running.
• Must support Barman Cloud's WAL directory layout and all its supported compression variants (none, gzip, bzip2, snappy), inferred from the file name.
• No key/path collision with Klio's own WAL layout in the same bucket: this must be confirmed as impossible, not assumed.
• Behaviour must be configuration-gated: fully inert when disabled, no extra object-store calls, no change to existing behaviour.

Verification

• WAL restore falls back to the Barman Cloud layout when a segment is absent from Klio's native archive, feature enabled.
• All three compression variants decompress correctly.
• With the feature disabled, behaviour and object-store call volume are identical to today.
• No key/path collision between Klio's layout and Barman Cloud's layout in the same bucket, confirmed by test.
• No write operation is ever issued against Barman Cloud objects, confirmed by test.
• Covered by unit tests against both layouts, and an integration/e2e test using a bucket seeded with Barman Cloud-formatted WAL.

Open questions

• Confirm whether Barman Cloud's WAL hash-dir sharding scheme matches Klio's own, or whether the two must be computed independently.

Out of scope

• Recovering a base backup in Barman Cloud format (sibling ticket).
• Retention/cleanup of legacy Barman Cloud objects (future ticket).