catalog-operator: wrap catalogsource pods in Deployments

[exdx]

Description of the change:

Updates the operator to produce Deployments instead of standalone Pods backing CatalogSources. This enables a node to be drained properly without forcing the catalog pods off the node.

Motivation for the change:

Multiple upstream and downstream bugs reported for this issue.

Architectural changes:

Testing remarks:

Reviewer Checklist

• [ ] Implementation matches the proposed design, or proposal is updated to match implementation
• [ ] Sufficient unit test coverage
• [ ] Sufficient end-to-end test coverage
• [ ] Bug fixes are accompanied by regression test(s)
• [ ] e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
• [ ] tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
• [ ] Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
• [ ] Docs updated or added to /doc
• [ ] Commit messages sensible and descriptive
• [ ] Tests marked as [FLAKE] are truly flaky and have an issue
• [ ] Code is properly formatted

[openshift-ci[bot]]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: exdx To complete the pull request process, please assign perdasilva after the PR has been reviewed. You can assign the PR to them by writing /assign @perdasilva in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[exdx]

Does this deserve it's own tracking issue that we can slate into the next minor version release? It seems like the motivation is geared towards a bug fix, but I'd worry about backporting these changes to a stable release, vs. a net new thing. Thoughts?

Yes, I'm not super thrilled about backporting this to stable release at this point either. I think, since it is a change in behavior, it should probably be slated to the next minor version downstream. I'm not sure about tracking this in an issue upstream though.

We have several issues already about this behavior:

• https://github.com/operator-framework/operator-lifecycle-manager/issues/2709
• https://github.com/operator-framework/operator-lifecycle-manager/issues/1514