Implement support for respecting upgrade graph semantics

[timflannagan]

Goal: Ensure the defined upgrade graph semantics are respected during upgrades. The current implementation always chooses the highest semver bundle in the desired package name without inspecting the upgrade graph semantics.

Needs Clarification on Scope:

• Ensuring cross-catalog upgrades are handled properly
• Ensuring cross-channel upgrades are handled properly
• Accommodating catalogs that define multiple bundle formats (as this doesn't exist today)

Open Questions:

• Do we need to leverage the OperatorConditions API to determine whether an Operator cannot be upgraded?
• How do we avoid blasting through the upgrade graph if there's no support at the rukpak layer for inspecting the runtime state of managed workloads?

[timflannagan]

cc @joelanford in case you have any thoughts on those open questions. It seems like having runtime checks in rukpak's plain bundle format would be needed here to avoid blasting through the defined upgrade graph semantics to avoid the following scenario:

• v0.1.0 is currently installed, and there's a v0.2.0 and v0.3.0 versions present in the catalog
• v0.2.0 is replaced by v0.1.0, and v0.3.0 replaces v0.2.0

Any implementation that simply looks at the replaces chain here would pivot to v0.2.0 once it's available, then the controller would catch the BD event and requeue, and then select the v0.3.0 as it's the highest semver available and there's no logic that can inspect the state of something like a deployment.

[timflannagan]

We'll also need to be able to delineate between "my operator cannot be upgraded right now as performing migration logic" and "my operator was able to successfully be applied to the cluster but it's failing at runtime" to have a more robust story about upgrades that doesn't exist in the current implementation.

[joelanford]

I imagine this will be in scope for an integration with deppy, where the operator controller has a way to tell deppy:

1. Here's what's installed
2. Here's what's upgradable (based on OperatorConditions and/or BD Health objects)