Barman Cloud compatibility: enforce retention against the legacy Barman Cloud archive

[gbartolini]

Problem

Once a cluster has migrated to Klio and the barman-cloud plugin is decommissioned, nothing enforces retention on the legacy Barman Cloud archive any more: its base backups and WAL will never be expired or deleted unless Klio takes over that responsibility. This is the one write/delete path against Barman Cloud objects deferred from the WAL fallback and base-backup fallback tickets.

Requirements

• This is the only write or delete operation Klio ever performs against Barman Cloud objects; the WAL and backup fallback paths remain strictly read-only.
• Deleting a Barman Cloud base backup must remove all of its constituent objects (all tablespace tars, data.tar, backup.info) completely: no orphaned objects left behind on partial failure.
• A Barman Cloud backup or WAL segment still required by a valid recovery target must never be deleted, regardless of the configured retention window.
• The local Barman Cloud catalog cache (sibling caching ticket) must reflect deletions immediately: it must not continue to offer deleted backups or WAL for restore.
• Feature is off by default and must be explicitly enabled; fully inert otherwise, with no object-store calls beyond normal fallback reads.

Verification

• Applying retention against a Barman Cloud archive deletes only backups/WAL segments genuinely beyond the configured retention window, confirmed by test.
• Deletion of a base backup is all-or-nothing: a partial failure (e.g. an object-store call fails mid-deletion) leaves no orphaned tablespace tars or dangling backup.info.
• A Barman Cloud backup or WAL segment still required by a valid recovery target is never deleted, confirmed by test.
• The local catalog cache reflects a deletion immediately after it completes: no stale entries served for restore afterwards.
• Feature is off by default; enabling/disabling it is the only thing that changes behaviour.
• Covered by an integration/e2e test against a real Barman Cloud archive, including a forced partial-failure scenario.

Open questions

• Does the legacy Barman Cloud archive get its own independent retention policy configuration, or does it inherit the cluster's existing tier2 retention policy?
• What triggers a retention pass against the Barman Cloud archive: the same schedule as Klio's native retention, a one-off manual trigger, or something else?
• How does this interact with the catalog cache's invalidation model, given the caching ticket left that open?

Out of scope

• Barman Cloud's own retention enforcement while it's still the active, pre-migration plugin.
• The WAL fallback and base-backup fallback read paths (sibling tickets, this ticket concerns deletion only).