Story: As a cluster-admin attempting to do a disconnected install of OpenShift I expect that by default the mirroring logic figures out which dependent operators need to be mirrored for any given Operator to be mirrored so that I can actually use the desired Operators in the disconnected cluster.

Side note: While we want this initially in opm it should be exposed in shareable code libraries so that oc can vendor in the logic easily.

Acceptance criteria:

• a shareable library that is implemented / used internally in opm and can later on be shared with oc
• input is an existing published "upstream" catalog with a floating image tag that will be updated over time with references to newer Operator versions
• a second input is "mirror" catalog that was created in an initial/previous mirroring operation at some point in the past
• the output is a slim catalog containing dependencies of either channel heads (heads-only mode) or all newest bundles (latest mode)
• the library adds the entire package needed to resolve a dependency to the mirror catalog
• the library is built into the opm CLI as opm alpha diff

Open Questions:

• how do we deal with dependencies that can only be fulfilled from other catalogs? is this a scenario we need to expect to be common? e.g. redhat-operator depending on community-operators
• In the future the OLM resolver should figure out for any Operator version that is mirrored which dependent Operators are required and mirror those as well. What are the challenges here?