Goal: Prototype a deppy implementation that's focused on PO requirements.

Summary: Implement a slimmed down Input API to prove out the system that sits between POs and rukpak APIs. Support only a small subset of constraint definitions that meet phase 0 POs requirements, at the cost of building out a pluggable constraint definition system in the short term. Interface with OLM's solver package and CatalogSource API for resolution and sourcing needs. Punt on designing any offline use cases.

AC:

• Create an Input API that has separate .Spec fields for properties/constraints, which are in the form of key/value pairs
• Support only a subset of constraint definitions (e.g. olm.package/olm.channel) out-of-the-box
• Interface with OLM's solver package and OLM's CatalogSource API
• Translate the constraints specified in the Input(s) in a cluster into a set of solver.Variable(s) that gets passed to the solver package
• Surface resolution decisions (e.g. as a list of resolved IDs in the status?)

Stretch:

• Add cluster-wide invariants (e.g. one GVK/package per cluster)
• Respect upgrade graph skip/replaces semantics
• Update the PO controller implementation to only interact with deppy API's
• Introduce the InputClass API and update the controller implementation
• Ensure existing resources are accounted for during resolution (e.g. BI resources are mandatory?

Open Question(s):

• What's the source of truth for properties: an FBC, or bundle-level metadata? At runtime, the catalog/FBC properties is the source of truth.
• Do we need a first-class resolution output API? It would appear that a top-level API is needed for clients to be able to declare their own constraints/requirements