There are multiple strategies to avoid races between containers when using Istio/OSSM: the older holdApplicationUntilProxyStarts which just makes sure that an application container waits until the proxy is ready before attempting to make requests, and the newer Sidecar API. We should add some documentation that outlines when to use which - it will be almost always Sidecar API, except if it is not available in your cluster, simply due to the fact that holdApplicationUntilProxyStarts is a solution that relies on ondocumented kube scheduler behavior whereas Sidecar API has guaranteed interface and behavior.

In 2.x, holdApplicationUntilProxyStarts was only available through the techPreview field. We will change that for 3.0 by making MeshConfig part of our API, and by that officially support all MeshConfig settings.

Acceptance Criteria:

• Document how to use Sidecar API with istio workloads (or point to relevant upstream docs)
• Mention that holdApplicationUntilProxyStarts is no longer Tech Preview

Original issue:

Make holdApplicationUntilProxyStarts GA and fully supported

Currently holdApplicationUntilProxyStarts feature is TechPreview only on OSSM v2.1 but there has been many customers wanting and needing to implement this feature for specific purposes and with that we are getting some requests from the customers to have this GA and fully supported.