[epic]: Minimal controls for selecting catalogs to resolve from

[joelanford]

Today, if multiple ClusterCatalogs exist on a cluster, they contain duplicate package names, and both catalogs contain bundles the meet the criteria of a ClusterExtension, the choice that our resolution process makes is currently undefined.

In this epic, we propose to provide users with one minimal control for catalog selection.

We would add a field to the ClusterExtension spec that gives users the ability to select over a subset of the catalogs to resolve from. This is intended to give users a similar experience as yum --enable-repo and yum --disable-repo.

In a design, we will propose an implementation that accounts for API conventions around standard patterns and anti-patterns for object selection.

• Brief
• RFC - Labels
• RFC - Priority

Sub tasks:

• Error on ambiguous resolution + test #1110
• Update the ClusterExtension API to include label selectors and update status #1111
• Hook label selection into resolution + test #1112
• Add mutating web hook to add ClusterCatalog name label + test - catalogd #1113
• ClusterCatalog label policy enforcement + test - catalogd #1114
• E2E tests for labeling webhooks and selector #1115
• Add priority field to ClusterCatalog API #1116
• Add support for ClusterCatalog priority to operator-controller #1117
• Add documentation for Minimal Catalog Selection #1154
• Follow up: use webhooks.matchConditions catalogd#370
• Move the cert-manager.io annotation patch  catalogd#371

[joelanford]

Brief: https://docs.google.com/document/d/1-SqENbwa3nrbYqrxaD7OfjyLXWdjuYBCUUEJPPA8r7U/edit#heading=h.btd8kkom5km4