release bundle attribute in version property

[grokspawn]

Description of the change:
Adds a new bundle-scoped "release" flag to the existing version property to allow for more sophisticated replacement strategies with improved transparency.
Adds a new substitutesFor catalog template to help folks trivially adopt the new approaches and avoid common error scenarios.

Motivation for the change:
As brief and RFC state, the imperative upgrade graph building process had a CSV attribute "substitutesFor" which allowed tooling to perform bundle-level replacement in resulting graphs. We had no equivalent FBC approach to the problem where there is a packaging-only change which we need to insert into an existing graph in a way that it didn't pretend to be the original bundle, but made it possible to prefer the new bundle over the old one, and even upgrade from the old to the new.

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Docs updated or added to /docs
• Commit messages sensible and descriptive

[openshift-ci]

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]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign camilamacedo86 for approval. For more information see the Code Review Process.

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

[codecov]

Codecov Report

❌ Patch coverage is 61.41304% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 57.58%. Comparing base (24737fb) to head (63fd4b0).
⚠️ Report is 8 commits behind head on master.

Files with missing lines	Patch %	Lines
alpha/template/substitutes/substitutes.go	67.04%	23 Missing and 6 partials ⚠️
alpha/template/converter/converter.go	0.00%	12 Missing ⚠️
alpha/model/model.go	79.31%	6 Missing ⚠️
pkg/registry/csv.go	45.45%	5 Missing and 1 partial ⚠️
pkg/registry/parse.go	64.70%	3 Missing and 3 partials ⚠️
pkg/registry/bundle.go	55.55%	2 Missing and 2 partials ⚠️
pkg/lib/validation/bundle.go	0.00%	2 Missing and 1 partial ⚠️
pkg/registry/registry_to_model.go	40.00%	2 Missing and 1 partial ⚠️
alpha/declcfg/declcfg_to_model.go	75.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1792      +/-   ##
==========================================
+ Coverage   55.37%   57.58%   +2.21%     
==========================================
  Files         136      137       +1     
  Lines       16003    13105    -2898     
==========================================
- Hits         8861     7547    -1314     
+ Misses       5987     4387    -1600     
- Partials     1155     1171      +16     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[grokspawn]

Please note that this repo's merge method is set to squash, so all of these commits will get squished to a single one even if I forget to do it manually.

They're preserved here mostly because there has been a lot of ground covered over the lifetime of this feature w.r.t. different implementation strategies, and I didn't want to lose that.

[joelanford]

This would parse successfully if the value of props.Packages[0].Release was 1+1. We would correctly get an error from line 146, but it would be confusing to a user, I think, because we're leaking that we expect the release to only contain "prerelease", which is kind of a out of left field unless you know that we just happen to use prerelease syntax for our release value specification.

I think it may be better to do something like this: https://github.com/joelanford/operator-controller/blob/2cf768082d2e4f129e6ec82740afab55201cbd8e/internal/operator-controller/bundle/versionrelease.go#L79-L101

[grokspawn]

The reason that I wanted to use this approach is because I wanted to leverage the version.Compare and version.Validate (as well as PRVersion.Compare)... including all the consistent messaging that semver offers from version.Parse in addition to our layered-on validations.

[grokspawn]

I think the leakage is actually not a bad thing. Since the underlying type is defined in this way already, is it actually even leakage?

[grokspawn]

But line 146 needs a fix, because with a synthetic semver.Version struct with explicitly zero major/minor/patch, those checks would be functionally NOOPs.