What?

Whenever an incompatible OpenShift Service Mesh (OSSM) Subscription resource is present, we will fail to provision Gateway API and report the problem.

Why?

Users might have deployed OSSM 2.x prior to upgrading to a version where the CIO provides Gateway API support via OSSM, and 2.x and 3.x (which Gateway API uses) are not compatible. We can't automatically resolve this problem at this time in a way that's safe for previous OSSM deployments utilizing that Subscription, so we must bail.

How?

The CIO logic should follow these guidelines:

IF a 2.x Subscription is present, AND a supported `GatewayClass` resource is created:
1. fail to create a OSSM 3.x Subscription (having 2.x and 3.x coexisting is not supported)
2. stop trying provision the Gateway API resources in any way
3. set a status on the GatewayClass that indicates the problem
4. set a Degraded status =True on the CIO which indicates the problem until either the GatewayClass is removed, or the 2.x subscription is removed
5. do any other reporting/logging that seems appropriate for the situation