BSL controller loop always invokes init() regardless of backup location's ValidationFrequency

[betta1]

What steps did you take and what happened:
After upgrading to Velero v1.5.1, we observed that BSL controller always invokes init() for existing backup storage locations regardless of the BSL's ValidationFrequency (we tried setting BSL validationFrequency to 0 to skip validation but this didn't help). This is an issue since for some objectstore plugins the init() method could be an expensive call, for instance our objectstore plugin init() method opens connection to the backup target and creates directories/buckets if they don't exist as part of initializing the backup repository. Looking at the Velero BSL controller code, we first initialize backupStore prior to the check for whether the BSL is ready to be validated:

                backupStore, err := r.NewBackupStore(location, pluginManager, log)
		if err != nil {
			log.WithError(err).Error("Error getting a backup store")
			continue
		}

		if !storage.IsReadyToValidate(location.Spec.ValidationFrequency, location.Status.LastValidationTime, r.DefaultBackupLocationInfo, log) {
			log.Debug("Backup location not ready to be validated")
			continue
		}

I think moving r.NewBackupStore() to after the check for whether BSL is ready to be validated will fix this issue to avoid invoking init() on all backup storage locations whenever the controller loop runs.

What did you expect to happen:
Setting BSL validationFrequency to 0 should skip validation for the backup storage location.

The output of the following commands will help us better understand what's going on:
(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:
[Miscellaneous information that will assist in solving the issue.]

Environment:

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

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"