[Test-Proxy] Enforce Http 1.1 only

[scbedd]

On both go 1.17 and go 1.18 we generate some wonky headers.

• :authority
• :method

It is an artifact of the client, as per my understanding these aren't actually used by the service. Correct me if I'm wrong @seankane-msft

In the past, we were actually silently omitting them, but we got explicit with this PR.

This PR brings it back to excluding them by default.

Kestrel by default listens for both http/1.1 and http/2 communication. The issue is that because we were allowing both, the go clients don't know which to select. This is why we are seemingly randomly getting :authority and :method headers. The go client thinks it's talking http/2!

By disallowing test-proxy from listening on http/2, we don't get those wonky headers sent anymore. The go client selects the correct protocol based on what our server tells it.

[mikeharder]

In HTTP v1, Header names are not allowed to contain the : character per the spec:

       message-header = field-name ":" [ field-value ]
       field-name     = token

https://datatracker.ietf.org/doc/html/rfc2616#section-4.2

       token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

https://datatracker.ietf.org/doc/html/rfc2616#section-2.2

Header names like ":authority" and ":method" appear to be valid in HTTP/2, so maybe Go is accidentally adding HTTP/2 headers to an HTTP v1 request?

I think the Go SDK should fix this issue and stop sending the invalid headers. It's possible services could reject the requests since they are invalid. I consider it a good thing that test-proxy detected this issue for us.

If we really need to allow test-proxy to accept these headers, I would put it behind an optional flag. It should only be enabled as a temporary measure until the SDK can be fixed to remove invalid headers.