Cross-Operator compatibility constraints

1. Proposed title of this feature request
Operator Collections

2. What is the nature and description of the request?
3. Why does the customer need this? (List the business requirements here)

As rhn-support-palsop put it: "The motivation for this RFE, epic, if you will, is simple: make the deployment of new & upgraded functions, add-ons, whatever we call them (including new versions of Red Hat products like virtualisation and data services), easy for hard-pressed operational staff with limited knowledge of Kubernetes or OpenShift and with a raft of other things to be concerned about."

IOW for the set of opertos that a customer is using: Provide a set of operator versions for the operators in question that were tested and known to be working.
The goal is to increase the operational safety. And increase the trust into OCP and it's operators.

4. List any affected packages or components.
OLM
OCS
CNV
knmstate
NHC (in future)

Additional summary from DanielMesser:

Seems like what you need is a way to pin down all of your dependencies to a specific level in a group-like fashion and deem a certain combination of versions as "works well" vs. certain others as "may work well" or "ymmv". As a customer I wouldn't be interested in the latter two. What I'd want is a system that keeps me on the supported, happy path without me accidentally falling off of it. One way is to build said service that can respond to a query, given a certain version combination and spit out a support statement. I don't see it being achievable, because the number of permutations to test is probably unmanageable. We would really need to test all versions of all operators, not just the one we directly deem related, for this to be reliable.
But it's not the only way to get the customer and us what we want. Instead of saying what works and doesn't work, we specify what works and everything else is considered not work (forcing function to keep customers on the happy path).

There is still also the idea of operator collections. We should probably, at some point, sit down and write this down in a fake README more clearly. But here's a high-level that I can see working:

• a operator collection is a packaging construct, that allows authors to ship a support matrix statement
• a collection defines an arbitrary number of operators, pinned down by exact version, which define a known to work well set
• a collection is also atomic, an install either succeeds entirely, that is, all operators are installed successfully, or it fails, as soon as one of the operators fails
• updates are the same as above, collections update from one set of known-to-work-well-together operators
• operators in can be marked as optional in a collection, i.e. they are useful, but not required for the collection to install (once part of the install they behave like above)

This would likely be a new declarative format that becomes part of FBC. We'd need to fiddle out how this works with existing concepts like channels or graphs, whether it builds on top of them or is completely independent.

Operator Collections will likely also have the functionality to be tied to OCP zstreams