Istio's ambient mode creates a fork in the road for users onboarding with OpenShift Service Mesh that they did not have before. Once the operator is installed, it creates a separate onboarding path and a separate upgrade path for users. We should validate the ambient lifecycle on OpenShift, as well as enough tests to have confident in our downstream builds (but not overly duplicate upstream testing).

Istio will also have 3 (4?) potential modes:

• Not in mesh
• Sidecar mode
• Ambient w/ ZTunnel
• Ambient mode w ZTunnel + Waypoint

A workload may have support for different features depending on the mode, and we will need to be able to map tests accordingly.

Keep "upstream first" in mind:

• We should re-use and not duplicate upstream testing
• Contribute to upstream testing where gaps are identified
  • Keep in mind that unlike Envoy, ZTunnel is an Istio-only component and does not receive testing outside of Istio
• Optimize downstream testing

"Coexistence" - we should also validate that OSSM in ambient mode can co-exist with a sidecar mesh on the same cluster. 

Not part of this epic:

• Migration from sidecar to ambient mode (can treat separately based on the upstream status of this feature)
• Multi-cluster testing (WIP upstream, status will align with upstream)
• Performance testing (to be handled by the perf team).