OTA-1580: "Promote" UpgradeStatus to Default (tests only)

This is a request for an [exception](https://github.com/openshift/enhancements/blob/master/dev-guide/featuresets.md#what-if-i-dont-have-automated-testing-reporting-into-component-readiness) in the feature promotion process.

Proposed promotion process:

1. Promote `UpgradeStatus` gate here. This does not actually put any functional change into customers' hands.
2. Promotion will allow tests tagged with `UpgradeStatus` to run in Default update jobs
3. Update-time tests will execute and feed results into Sippy feature view
4. The feature view will need to be monitored manually to meet the criteria otherwise enforced by `verify-feature-promotion`
5. Once that happens, _actually_ promote the feature through openshift/oc#2063

Why is exception needed:

The feature promoted under `UpgradeStatus` gate identifier is actually entirely client-side implementation of the `oc adm upgrade status` command. Promoting the feature in o/api has no effect on any functionality in the cluster; nothing reads and depends on this identifier in the cluster (as of Jul 23, with the exception of the about to be removed behavior, tracked in OTA-1578 / openshift/cluster-version-operator#1216 expected to merge soon). The actual "promotion" of the feature would be done in the o/oc repository with a PR such as openshift/oc#2063 (intentionally `/hold` for now because of its "feature promotion" semantics).

We wanted to utilize the `UpgradeStatus` gate to pursue the data-driven promotion process, but the process does not seem to accommodate features tied to OCP updates. Features are expected to accumulate test coverage in TechPreview (TP) jobs, but there are no TP jobs that exercise a cluster update. Minor version update TP cannot exist by definition (`TechPreviewNoUpgrade`). Patch version update jobs can exist in theory, but is likely that OCP cannot realistically maintain such jobs because teams are allowed to make update-breaking changes in TP (such as promotion where a v1alpha1 API will be replaced with a v1 one) until the version is GA. That means update-related features cannot easily accumulate sufficient test data in available TechPreview jobs (we may need to address this gap in the future because the exception process proposed here will not succeed for cluster-side behavior).

For this feature specifically, running in TechPreview jobs would actually increase risk of problems after promotion. The conditional behavior is entirely client-side; testing it against TP clusters carries a risk of inadvertedly depending on some cluster-side TP-only feature. Such feature could be missing in Default clusters and the client-side behavior can break when run against a Default cluster. For CLI-side features, it seems more appropriate to test TP behavior against a Default cluster instead. This is possible, but non-TP jobs will not execute tests tagged with a TP feature gate name such as `FeatureGate`.

How are regressions prevented:

- Promoting `UpgradeStatus` in o/api has no risks because it does not change any behavior except test selection
- Running candidate CLI behavior against Default clusters actually provides better quality signal than against TP clusters
- Tests tagged with `UpgradeStatus` will need better scrutiny before merge because they will run in Default jobs and not just TP jobs
- The actual promotion in o/oc is still gated by data evidence of passing tests, in spirit with the usual promotion process

Author: petr-muller

features/features.go

@@ -430,7 +430,7 @@ var (
 					contactPerson("pmuller").
 					productScope(ocpSpecific).
 					enhancementPR(legacyFeatureGateWithoutEnhancement).
-					enableIn(configv1.DevPreviewNoUpgrade, configv1.TechPreviewNoUpgrade).
+					enableIn(configv1.DevPreviewNoUpgrade, configv1.TechPreviewNoUpgrade, configv1.Default).
 					mustRegister()
 
 	FeatureGateTranslateStreamCloseWebsocketRequests = newFeatureGate("TranslateStreamCloseWebsocketRequests").