Description of problem

Make customers running disconnected aware that 4.21 will require the SigStore signatures of OpenShift to be present (per OCPSTRAT-2471). This will make them know in advance that they need to use an OCI-compatible registry for their image mirror and use the oc-mirror version aligned with the OpenShift 4.21 release to automatically mirror the OpenShift 4.21 payload, to ensure it also captures the signatures.

Version-Release number of selected component

This ticket is asking for 4.20 guards to warn cluster admins before they launch an update to 4.21.

How reproducible

Every time.

Steps to Reproduce

1. Install a 4.20 standalone cluster.
2. Configure any ImageContentSourcePolicy or ImageDigestMirrorSet.
3. Wait some reasonable time like 5 minutes to allow for context sharing among the robots.
4. Check the ClusterVersion Upgradeable condition:

$ oc get -o jsonpath-as-json='{.status.conditions[?(@.type == "Upgradeable")]}' clusterversion version

Actual results

No warning about what's coming in 4.21.

Expected results

An explicit Admin Ack is required to update from 4.20 to 4.21, if the cluster has image mirrors configured (via ICSP or ITMS or ICSP). The cluster admin has to explicitly acknowledge that their registry is capable of storing SigStore signatures (OCI 1.0 compatibility) and that they have used oc-mirror in version 4.21 or newer to mirror the images for 4.21 or newer.

Additional info

I don't think ImageTagMirrorSets are relevant, because we currently only sign releases by digest (ART-10109 is wondering about maybe signing by tag too in the future).

HyperShift cluster updates are not exposed because they run their release image-based CVOs on the management cluster, and a HostedCluster update will only pull in the openshift ClusterImagePolicy on the hosted cluster.

HyperShift clusters will need their release images to have Sigstore signatures available to the management cluster by the time the management cluster is updated to 4.21.  Most management clusters I'm aware of are standalone, although I guess it's possible that folks are running HyperShift for management clusters.  Not sure what to do about protecting those, because as I understand it, there's no MCO there. Maybe whatever handles mirror configuration rendering in HyperShift could handle this guard there too, but I'm leaving that out of scope for this bug.