Adds new catalogmetadata package

[m1kola]

Description

Adding a new package to deal with catalog metadata.

We will be using it to replace existing enttiy soruces. At the moment catalogmetadata package contains:

• Types which embed declcfg.Package, declcfg.Channel and declcfg.Bundle.
  Later we will be adding more methods to them (for unmarshalling properties, for example). This PR already extends Bundle type.
• A function to unmarshal catalog metadata into Package, Channel or Bundle structs.

catalogmetadata/filter subpackage:

• Filter function which can filter all these 3 types using a given predicate
• And, Or and Not composite predicates to be used with Filter
• A set of predicates for bundles

catalogmetadata/client subpackage:

• A client for fetching bundles (today we get info from kube API server, but later we will switch implementation to use catalogd HTTP server).

catalogmetadata/sort subpackage:

• Functions to sort catalogmetadata structs (e.g. byndles by version).

---

This will eventually replace the following:

• internal/resolution/entities
• internal/resolution/entitysources
• internal/resolution/util/predicates
• internal/resolution/util/sort (most likely)
• cmd/resolutioncli/entity_source.go

Reviewer Checklist

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

[codecov]

Codecov Report

Patch coverage: 95.18% and project coverage change: +2.00% 🎉

Comparison is base (1ec4a23) 81.64% compared to head (d555222) 83.65%.
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #393      +/-   ##
==========================================
+ Coverage   81.64%   83.65%   +2.00%     
==========================================
  Files          21       27       +6     
  Lines         937     1101     +164     
==========================================
+ Hits          765      921     +156     
- Misses        119      123       +4     
- Partials       53       57       +4     

Flag	Coverage Δ
e2e	61.92% <ø> (+0.13%)	⬆️
unit	80.29% <95.18%> (+3.05%)	⬆️

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

Files Changed	Coverage Δ
internal/resolution/entities/bundle_entity.go	98.27% <ø> (-0.03%)	⬇️
...ternal/catalogmetadata/filter/bundle_predicates.go	89.18% <89.18%> (ø)
internal/catalogmetadata/client/client.go	89.47% <89.47%> (ø)
internal/catalogmetadata/filter/filter.go	100.00% <100.00%> (ø)
internal/catalogmetadata/sort/sort.go	100.00% <100.00%> (ø)
internal/catalogmetadata/types.go	100.00% <100.00%> (ø)
internal/catalogmetadata/unmarshal.go	100.00% <100.00%> (ø)

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

[stevekuznetsov]

Is there a quick summary of why this change is being proposed?

[m1kola]

@stevekuznetsov we are looking into ways to remove entities and entity sources from operator-controller. This is just me playing with how we might interact with the catalog data. See #375 for actual removal (still WIP).

[dtfranz]

Should we not also sort by package name as we did before with entities? If we don't, what I'm imagining is our list of:

- packageName: a-package
  version: 1.0.0
- packageName: b-package
  version: 2.0.0
- packageName: a-package
  version: 3.0.0

would get sorted to:

- packageName: a-package
  version: 3.0.0
- packageName: b-package
  version: 2.0.0
- packageName: a-package
  version: 1.0.0

instead of getting grouped up by name followed by version:

- packageName: a-package
  version: 3.0.0
- packageName: a-package
  version: 1.0.0
- packageName: b-package
  version: 2.0.0

[m1kola]

I think ordering by package is not important. We have the following use cases for old bundle entity based sort.ByChannelAndVersion at the moment:

• RequiredPackageVariableSource - here we always filter by pacakge name so all bundles in sorting will have the same package name. For package name filtering we set a predicate here.
• Twice in InstalledPackageVariableSource - on the first occasion we call it on a slice filtered by bundle image (so most likely same package) and on the second occasion we call it on a slice filtered by replaces which should also be within the same package
• BundlesAndDepsVariableSource - here is the use case where we might sort different packages. A bundle might require multiple GVKs from different pacakge. But, I think, as long as dependencies are sorted by version from newest to oldest we should be ok.

[dtfranz]

Awesome that makes perfect sense, thanks for the explanation!

[m1kola]

I'm not 100% that this is correct, but let's go with it and fix it if it doesn't work. Trying to not overcomplicate it :)

[dtfranz]

LGTM!