Add service_protocol field to Sidecar API

[wtzhang23]

Istio supports Ingress Sidecar Termination, which allows configuring sidecars to terminate using certs provisioned elsewhere given that the ENABLE_TLS_ON_SIDECAR_INGRESS feature flag is set to true. This helps new users of Istio take advantage of Istio features such as inbound stats collection and injected EnvoyFilters while migrating their infrastructure stacks over the span of multiple years. Note that migration cannot be accelerated as it requires onboarding every client, and we have many services that have a high fan-in count (e.g. configuration services, facades over user databases).

However, the current implementation only supports passing traffic to the service over HTTP/1.1. As gRPC and other HTTP2-based protocols gain popularity, this means that users cannot use this feature out-of-the-box. EnvoyFilters can be used to patch this.

This PR proposes an ergonomic change which allows specifying the service_protocol that differs from the protocol specified in the sidecar port. The following changes (original closed PR) show how this would be implemented:

• If blank, continue as was before
• If the sidecar protocol is HTTPS, allow service_protocol to be either http or http2
• If the sidecar protocol is TLS, allow service_protocol to be a TCP protocol (e.g. Redis)
• Else, the sidecar protocol must match the sidecar port protocol if specified.

[istio-policy-bot]

😊 Welcome @wtzhang23! This is either your first contribution to the Istio api repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[istio-testing]

Hi @wtzhang23. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.