Seamless migration from the CloudNativePG Barman Cloud plugin to Klio plugin

[gbartolini]

Enable an existing CloudNativePG cluster on the Barman Cloud plugin to cut over to Klio without losing the ability to recover across the cutover boundary, and without requiring any migration or rewrite of previously archived data.

Why

On cutover, Klio starts archiving forward into the same object store under its own layout. The pre-existing Barman Cloud archive isn't
migrated or rewritten. It simply stops accepting new writes and becomes a static, legacy archive that Klio must be able to read from (for recovery targets that predate the cutover) and eventually retire as part of tier 2 retention policies.

What

• Barman Cloud catalog cache: build a local cache of the (static) legacy archive on enablement, rather than re-listing/re-parsing the object store per lookup.
• WAL restore fallback: read WAL segments from the Barman Cloud layout when absent from Klio's native archive, read-only.
• Base backup restore fallback: read tar-mode Barman Cloud base backups when a requested backupID isn't in Klio's native catalog, read-only.
• Retention enforcement — the one write/delete path against Barman Cloud objects, expiring legacy backups and WAL once they fall outside the configured retention window.

Success criteria

• A cluster cuts over from the Barman Cloud plugin to Klio with zero data loss and no manual migration step.
• Recovery targets that predate the cutover succeed, transparently pulling WAL and/or base backups from the legacy Barman Cloud archive as needed.
• Recovery targets that postdate the cutover are served entirely from Klio's native archive, with no dependency on the legacy one.
• The legacy Barman Cloud archive is eventually retired under Klio's own retention, without ever requiring the barman-cloud plugin to be reinstalled.
• Each sub-issue is independently verified against its own acceptance criteria.

Dependencies

The catalog cache is intended to serve both fallback tickets; whether and how each depends on it is left open, to be decided on those tickets. Retention depends on the cache's invalidation model, which is itself an open question on the caching ticket.

Out of scope

• Migrating or rewriting the legacy Barman Cloud archive into Klio's own format (unless under analysis we think this is a better approach)
• Ongoing, indefinite coexistence between the barman-cloud plugin and Klio: the plugin is expected to be decommissioned at cutover, not run alongside Klio long-term.
• Migrating back from Klio to the Barman Cloud plugin.