User Story:

• As a Deppy User, I would like to use Deppy to consider if a set of constraints can be met by content within a catalogSource.

Background:

• For OpenShift 4.13, the Operator Runtime team is attempting to hit the first milestone of OLM V1 which consists of an MVP capable of installing an operator.
• The operator that the MVP installs will ultimately need to come from an existing catalogSource, as the alternatives would require implementing a new storage API for an operator, which was deemed too much work for 4.13.
• As such, the team has opted to wrap the existing registry client within a "Deppy Source Interface", constraining the Deppy library to only sourcing content from catalogSource but allowing us to reach the e2e milestone quickly.
• This approach will also allow us to write most of the code that will eventually be used by the "DeppySource catalogSource adapter" to convert existing content into the  format desired by Deppy.

Acceptance Criteria:

• Deppy can be provided with a catalogSource, treat it as an EntitySource, and retrieve the bundles and store them in a cache.
• Deppy can be notified that a catalogSource has been updated, retrieve the new content, and update the cache.
• Deppy can be notified that a catalogSource has been deleted and remove that source and it's entities from the cache.
• A test is implemented ensuring that Deppy can communicate with catalogSources.

Upstream Issue:

• https://github.com/operator-framework/deppy/issues/76