feat: serve restore hooks from the instance sidecar

[ermakov-oleg]

Serve restore hooks from the instance sidecar (CloudNativePG 1.31 support)

Motivation

CloudNativePG no longer bootstraps new instances in a separate Job (cloudnative-pg/cloudnative-pg#11319, part of 1.31.0). The restore now runs in the bootstrap-instance init container of the instance pod, so the operator sends the Restore RPC to the sidecar inside that pod. This plugin only registered the restore hooks in the full-recovery Job sidecar. As a result, every bootstrap.recovery (including PITR and replica clusters bootstrapped from a backup) hangs on bootstrap-instance on CloudNativePG main. This is the pgBackRest counterpart of cloudnative-pg/plugin-barman-cloud#1025.

Changes

• The instance sidecar registers the existing restore-job hooks (JobHookImpl) and advertises TYPE_RESTORE_JOB.
• The pod lifecycle hook injects the sidecar:
  • always, when the cluster archives or follows a replica source;
  • for a recovery-only cluster, only until status.currentPrimary is set, which the instance manager does once bootstrap completes.
• Validate() accepts a configuration that references only a replica-source Archive.
• The instance sidecar takes instanceSidecarConfiguration from the first configured Archive: archive, then recovery, then replica source. Before, a recovery-only cluster would restore without the recovery Archive's resources and security context, and a replica-source-only cluster would never get its Archive's settings.
• The Job hook is unchanged, so CloudNativePG ≤1.30 keeps restoring in the full-recovery Job.

Visible behaviour changes

• Recovery-only clusters (restored with this plugin, no own archive) now get the sidecar during bootstrap on every CloudNativePG version. Once bootstrap completes, the operator's drift check rolls the pods once to remove it: a switchover when a replica exists, otherwise an in-place restart. With primaryUpdateStrategy: supervised, that rollout waits for a user-issued switchover or restart, as any other pod spec change would.
• Replica-source-only clusters (replica cluster following a pgBackRest source, no own archive) now keep the sidecar permanently, so WAL can be restored from the source archive in the instance pods. Existing clusters of this kind roll once when the plugin is upgraded.
• For a cluster with both an archive and a recovery source, the in-pod restore on 1.31+ uses the archive Archive's sidecar resources. The 1.30 Job used the recovery Archive's resources. This matches plugin-barman-cloud.

Testing

• Unit tests:
  • sidecar injection rules, including recovery-only clusters before and after bootstrap;
  • Archive precedence for sidecar settings;
  • replica-source-only validation;
  • instance capabilities.
• New e2e spec: restore into a 2-instance recovery-only cluster. It checks that the cluster ends Ready, that no instance pod carries plugin-pgbackrest, and that the restored data is present.
• The full e2e suite passed locally on kind against CloudNativePG main (8/8) and v1.30.0 (8/8).

Notes

• Stacked on fix(e2e): run MinIO from the Chainguard images #155, which moves the e2e MinIO to the Chainguard images: minio/minio is gone from Docker Hub and quay.io/minio/minio now requires authentication. The first commit of this branch is fix(e2e): run MinIO from the Chainguard images #155's and drops out once it is merged.
• Independent of feat: delete Backup objects not present in the pgBackRest catalog #152. If feat: delete Backup objects not present in the pgBackRest catalog #152 lands first, its CloudNativePG v1.30.0 pin in test/e2e/e2e_suite_test.go should be dropped, so that e2e covers the new bootstrap flow again.

https://claude.ai/code/session_01MK4vZ6U6TZvXVLPViN1crd