backups: a cnpg Backup without a running BackupJob does not hold the WAL archive destination #5278

Describe the bug

After #5221 a Postgres BackupJob writes the shared WAL archive destination (the ObjectStore the Cluster's barman-cloud plugin archives to) only before its own cnpg.io/Backup exists, and only while no other running BackupJob of the application has a cnpg.io/Backup in flight. The queue deliberately counts only Backups whose owning BackupJob is still running, so two kinds of in-flight Backup do not hold the destination:

1. A cnpg.io/Backup with no owning BackupJob: one created by hand, by a ScheduledBackup, or by anything else outside the backup controller.
2. A cnpg.io/Backup whose BackupJob was deleted, or reached Failed, while the Backup was still pending or running.

When the next BackupJob of the application uses a different BackupClass, it rewrites the destination under such a Backup, and the base backup and the WAL it needs can end up in different places, so the Backup cannot be restored from. Before #5221 every running BackupJob rewrote the destination every few seconds regardless, so this is not a regression of that PR; it is the part of the problem the queue does not cover.

Environment

• Cozystack main after fix(postgres): stop backup jobs from fighting over the WAL archive destination #5221
• Any provider

To Reproduce

1. Give a Postgres application two BackupClasses whose CNPG strategies point at different destinations.
2. Create a cnpg.io/Backup for the application's Cluster by hand (plugin method), or create a BackupJob and delete it while its cnpg.io/Backup is still pending.
3. While that Backup is pending or running, create a BackupJob that uses the other BackupClass.
4. The new BackupJob writes its destination to the ObjectStore and creates its own Backup.

Expected behaviour

The destination is not rewritten while any cnpg.io/Backup of the Cluster that already started writing is still in flight, whoever created it, and the wait is bounded so a stuck Backup cannot stall every later backup of the application.

Actual behaviour

The queue skips Backups without a running owning BackupJob, so the new job rewrites the destination under them.

Logs

Not applicable: the behaviour follows from the queue's selection of holders.

Screenshots

Not applicable.

Additional context

Holding for these Backups needs a bound the missing owner can no longer provide, for instance waiting only for Backups in an active phase, or for the CNPG Backup deadline, and then going ahead with a condition that names the Backup. The atomic per-application claim discussed in #4559 would be the natural place to also cover backups racing each other. Raised by an automated review on #5221.

Checklist

• I have checked the documentation
• I have searched for similar issues
• I have included all required information
• I have provided clear steps to reproduce
• I have included relevant logs