Historic details in https://issues.redhat.com/browse/NE-1139

This Epic covers two use cases:

• As an admin user of Service Mesh, I want to know how to turn on Gateway API and still maintain a single control plane.
• As an admin user of Gateway API, I want to know how to turn on Service Mesh and still maintain a single control plane.

Coordination between NE and OSSM teams needed.  Discussion areas include:

• Namespaces probably determine managed (by c-i-o) vs unmanaged Gateways (whether in/outside openshift-ingress namespace)
• Decision - can we just always have service mesh enabled, but not watching every namespace? (check with Marc)
• Should we have cluster ingress operator install/configure the service mesh objects/control plane for mesh use cases?
• Can we remove the adhoc installation of service mesh and make it easier to install via c-i-o?
• Can we create a shared Istio operator?
• Others?

We need to decide what things need to be configurable by the cluster admin, and how the cluster admin would configure these things.  To the latter point,

Consider adding a new OpenShift-specific config CRD to specify the following:

• Whether Gateway API/ingress is enabled.
• Whether Istio API/mesh is enabled.
• Istiod profile.
• Automatic deployments (if this should be configurable). 

The outcome of this story is some brief documentation including pros and cons of various methods to of configuring a new Gateway API installation while using Service Mesh, as well for as a new Service Mesh installation while using Gateway API; and a summary with a proposed recommended solution.

NE-1290 discusses various methods and features that could be configured.

Stretch goal - implementation of the research.