OCP4.9/kube1.22 is removing a bunch of previously deprecated apis:
https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22

We need to ensure that 4.8 clusters with workloads using those apis are not upgraded to 4.9 without explicit admin acknowledgement of the risks.

 
Acceptance criteria:

• An admin must explicitly update a resource on the cluster prior to upgrading to 4.9, to acknowledge the api removal
• The "update a resource mechanism" is generic and can be repurposed in the future
• The "update a resource mechanism" requires the admin to specify a field/key name that makes it clear what they are ACKing
• We have documentation that explains what apis are going away, and how to use OCP apiserver metric+endpoint capabilities to list what apis are in use on their cluster, and the limitations of those tools
• the documentation must also explain to the admin how to set the "ack" on their cluster that indicates they've done the investigation and want to allow the upgrade to proceed.
• Admins can still use "force" to bypass the the upgrade block, rather than doing the resource update ACK
• The UI makes it clear to an admin that they cannot upgrade to 4.9, why they cannot, and what they need to do in order to be able to upgrade.
• SD, ACM, IKS/ROKS, Hive, and Hypershift teams have been engaged so they understand what is coming here and can prepare for how they will manage this upgrade requirement for fleets of clusters under their tooling's management. We do not want SD(for example) to find out at 4.9GA that they can't upgrade their clusters without writing new tooling to update a config resource, or that they don't have a way to present the upgrade warning to their customers.

This work will require a new enhancement proposal and should start there.

Refer: https://bugzilla.redhat.com/show_bug.cgi?id=1978376
Refer: https://docs.google.com/document/d/1tI68t1CsoyT-skdxVfDGYF3Bdi6-P9P4cwT5ff--irk/edit