Support for non-image bundle types

[m1kola]

There are several places where we rely on bundle being an image. With the plan to support more types (such as git repos) we need to refactor operator controller to not assume image type.

Here are a few places where this is happening at the moment:

https://github.com/operator-framework/operator-controller/blob/e001a0f6ffd62fc478148463ad9b39a7b2e404a3/internal/controllers/operator_controller.go#L287-L291

https://github.com/operator-framework/operator-controller/blob/e001a0f6ffd62fc478148463ad9b39a7b2e404a3/internal/resolution/variablesources/bundle_deployment.go#L41

[m1kola]

For identifying installed bundle and its successors (currently in BundleDeploymentVariableSource) we can do something like below:

1. For BundleDeployments with Installed=True condition, compute a digest of its .Spec.Template.Spec.Source.
2. When looking at bundles in the catalog, we figure out what the .Spec.Template.Spec.Source would be if we were to select that bundle, and compute that digest.
3. If the digests match, we look for successors of item (2) in the catalog and add all of them to our successors list

This will make the process to not rely on a specific source type.

@joelanford please let me know if I captured it incorrectly

[joelanford]

Yeah, I think this sounds correct. I know that @varshaprasad96's rukpak v1alpha2 work is going to change this to an extent.

Also, I think we're headed in a direction where the catalog contains a BundleDeployment.spec (or template of one) that would potentially simplify this. Operator controller would no longer have to derive a BD. It would just have it from the catalog.