⚠️ allow filtering with a list of channels

[everettraven]

Description

• Updates the ClusterExtension.Spec.Channel field to now be ClusterExtension.Spec.Channels and accept a list of channel names for filtering of bundles during resolution

• Updates resolution logic, unit, and e2e tests as necessary

• ResolvesUpdate the ClusterExtension.Spec.Channel field to be a list of channels #1150

Reviewer Checklist

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

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	690c2ce
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/66d9f873f5f8e6000812f7fa
😎 Deploy Preview	https://deploy-preview-1173--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.

[codecov]

Codecov Report

Attention: Patch coverage is 92.30769% with 4 lines in your changes missing coverage. Please review.

Project coverage is 76.49%. Comparing base (75bb03d) to head (690c2ce).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
api/v1alpha1/zz_generated.deepcopy.go	0.00%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1173 +/- ##
==========================================
- Coverage 76.59% 76.49% -0.11% 
==========================================
Files 40 40 Lines 2329 2340 +11 ==========================================
+ Hits 1784 1790 +6 - Misses 389 393 +4 - Partials 156 157 +1 

Flag	Coverage Δ
e2e	57.64% <55.76%> (-0.06%)	⬇️
unit	52.43% <92.30%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tmshort]

I tried this once (an error generation function) and there was opposition to it. At that time, it was called in multiple places, this seems to be simply pulling out the code into a function, without any additional callers.

[tmshort]

(And of course, this requires changing all the error messages)

[everettraven]

I pulled it out into a separate function because the linter was complaining about the nesting depth being too high.

Regarding changing all the error messages, I found it a bit more complex to read the previous error logic in a switch statement and thought it was a bit more readable using this new strings.Builder approach because it is more linear in nature (i.e as you read each line of the code you see the scenarios that result in new information being added to the error string we return).

[everettraven]

If folks prefer the previous approach, I can revert this change.

[tmshort]

I don't care, I just wanted to make the note.

[tmshort]

/lgtm

[openshift-ci]

New changes are detected. LGTM label has been removed.

[joelanford]

Hmm, I didn't realize this test ignored the message. Follow-up?

[everettraven]

Is there a specific reason we should be testing the message?

I understand wanting to verify our message crafting logic is correct, but I lean towards the camp where the message is any arbitrary string and is not part of our API guarantees - testing for it explicitly makes our unit tests brittle