BackupRepository state not updated when repository fails at non-maintaining stage

[blackpiglet]

What steps did you take and what happened:

• Create a successful filesystem backup.
• Delete the config file of the backup repository from the OSS.
• Delete the backup.
• Backup hangs in the Deleting state.
• The BackupRepository state is still in the Ready state.

What did you expect to happen:
The Velero server should detect the backup repository corruption, then make the backup the Failed state, and the BackupRepository the NotReady state.

The following information will help us better understand what's going on:

If you are using velero v1.7.0+:
Please use velero debug --backup <backupname> --restore <restorename> to generate the support bundle, and attach to this issue, more options please refer to velero debug --help

If you are using earlier versions:
Please provide the output of the following commands (Pasting long output into a GitHub gist or other pastebin is fine.)

• kubectl logs deployment/velero -n velero
• velero backup describe <backupname> or kubectl get backup/<backupname> -n velero -o yaml
• velero backup logs <backupname>
• velero restore describe <restorename> or kubectl get restore/<restorename> -n velero -o yaml
• velero restore logs <restorename>

Anything else you would like to add:

Environment:

• Velero version (use velero version): main
• Velero features (use velero client config get features): None
• Kubernetes version (use kubectl version): v1.27
• Kubernetes installer & version: GKE
• Cloud provider or hardware configuration: GCP
• OS (e.g. from /etc/os-release): Ubuntu

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "I would like to see this bug fixed as soon as possible"
• 👎 for "There are more important bugs to focus on right now"

[reasonerjt]

There may be other cases the backupRepository CR's Status is not updated, let's also cover the other cases.

[reasonerjt]

Related to #7810

The general issue is that the CR's state is not updated in different error state. Given currently the state will be updated in next maintenance job, this is not ideal, but we can leave it in the backlog for v1.16.