:sparkles: refactor ClusterExtensionReconciler.reconcile()

[everettraven]

Description

Makes the reconcile method on the ClusterExtensionReconciler easier to unit test by encapsulating distinct operations as interfaces that can be mocked:

• (Done before this PR) Resolution is now done via a Resolver interface.
  • (Done as part of this PR) Bundle validation is now done by the Resolver. The reasoning behind this is that it reduces the complexity of the reconcile method by making the assumption that the configured Resolver will always return a valid bundle. Validation unit tests that existed in the internal/controller package have been moved and updated in the internal/resolve package
• Unpacking was unchanged
• Installation of content is now abstracted into a more generic Applier interface. This makes it easier to, in the future, swap out the underlying installation method by implementing a new Applier interface and swapping it out for the existing one. The existing Helm-based installation logic was moved to an implementation of this interface.
• Watching of managed resources was moved to a new Watcher interface that was implemented as part of the provided service account work. This was going to be a change that took place in the near future. From a functionality perspective, nothing should have changed.
• Unit tests added for the ClusterExtensionReconciler.reconcile() method

Reviewer Checklist

• [ ] API Go Documentation
• [ ] Tests: Unit Tests (and E2E Tests, if appropriate)
• [ ] Comprehensive Commit Messages
• [ ] Links to related GitHub Issue(s)

[netlify[bot]]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	dcd37f04daedec62c93ec9592cb45eb22d127481
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/66acee810502b8000801f846
😎 Deploy Preview	https://deploy-preview-1068--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[joelanford]

Nice! I like this idea. I'll take a closer look at this tomorrow, but one thing I would suggest off the bat is talking to @thetechnick about the Applier interface. I was chatting with him last week about experimenting with plugging package-operator's apply logic into operator-controller. I figure having a second implementation candidate would help validate our ideas behind the shape of that interface.

[thetechnick]

I do have a very rough first PoC here: https://github.com/thetechnick/operator-controller/pull/1 It directly uses Package Operator APIs to offload bundle reconciliation, so operator-controller just has to create a ClusterPackage, read status from it and lean back, while getting features similar to the OLMv0 Subscription config for free.

[everettraven]

@joelanford Sounds good. Are you thinking to utilize the ClusterPackage similarly to what @thetechnick has done (via the PoC) or more along the lines of importing the apply logic and using it as a library?

I'd be a bit hesitant to move back to an approach where we are creating an underlying resource like the ClusterPackage since we intentionally decided to deviate from that approach relatively recently (~3ish months ago).

[everettraven]

I will squash commits after reviews are fully addressed

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 56.91057% with 53 lines in your changes missing coverage. Please review.

Project coverage is 75.28%. Comparing base (989a3df) to head (dcd37f0).

Files	Patch %	Lines
internal/applier/helm.go	41.97%	35 Missing and 12 partials :warning:
cmd/manager/main.go	70.00%	2 Missing and 1 partial :warning:
internal/catalogmetadata/filter/successors.go	0.00%	3 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #1068 +/- ## ========================================== - Coverage 75.65% 75.28% -0.38% ========================================== Files 31 33 +2 Lines 1902 1861 -41 ========================================== - Hits 1439 1401 -38 - Misses 320 321 +1 + Partials 143 139 -4 ``` | [Flag](https://app.codecov.io/gh/operator-framework/operator-controller/pull/1068/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=operator-framework) | Coverage Δ | | |---|---|---| | [e2e](https://app.codecov.io/gh/operator-framework/operator-controller/pull/1068/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=operator-framework) | `56.85% <48.78%> (-1.20%)` | :arrow_down: | | [unit](https://app.codecov.io/gh/operator-framework/operator-controller/pull/1068/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=operator-framework) | `52.17% <23.57%> (+2.43%)` | :arrow_up: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=operator-framework#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tmshort]

Looks reasonable to me, but needs a rebase.