Add Per-HTTPProxy HTTP-Version Support to Address HTTP2 Coalescing Issues with Wildcards

[m-yosefpor]

Description:

With the emergence of the HTTP2 Coalescing issue, where using a wildcard can result in complications in SNI-based routing (as fully discussed in multiple issues including #1493), we've recognized a critical need to have a per-HTTPProxy mechanism to specify HTTP versions. This issue is exacerbated by browsers like Safari (or potentially underlining WebKit/CFNetwork) which does not retry upon receiving an HTTP 421 response. The proposed workaround for this issue is to universally disable http2 as mentioned in #2619 and implemented in #2622

We propose, adding a new field to the HTTPProxy spec allowing the specification of HTTP versions to offer for that HTTPProxy. This field comes into play only when spec.tls is activated and spec.tcpproxy is deactivated.

Critical Use Case:

In scenarios where multiple HTTPProxies are served, and a subset of them use the same wildcard certificate, it becomes imperative to have the flexibility to disable http/2 for specific proxies to avoid the mentioned issue. Meanwhile, we want to retain the performance advantages of http/2 for others, and also to be able to use gRPC routing for routes.

Proposed Solution:

1. Selectively disable http/2 for HTTPProxies using the wildcard certificate, thus bypassing the 421 issue for problematic browsers.
2. Retain the http/2 functionality for other routes to capitalize on grpc and enhanced performance.

Request:

Providing users the granularity to specify HTTP versions on a per-proxy basis, addressing the HTTP2 Coalescing challenge while balancing performance considerations. Furthermore, to ensure backward compatibility, if the new field in the HTTPProxy spec is not explicitly set, the behavior would default to using default-http-versions from the global configuration, provided it's not empty.

[sunjayBhatia]

Apologies, we got a bit behind reviewing the PR for this issue, bumping to 1.29.0

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack