Allow clients to select ALPN protocols instead of forcing HTTP/2

[anushka567]

Description

This PR carries forward the changes from #159 (by @sruthi-talluri) to allow clients to select ALPN protocols instead of forcing HTTP/2, and addresses the review feedback on that PR.

Background

GetTLSConfigurationForClient has hardcoded NextProtos to {"h2"} since #72, which was added when s2a-go was only used for gRPC. The HTTP entry points added later (NewTLSClientConfigFactory and NewS2ADialTLSContextFunc) inherited that default, so an HTTP/1.1 client gets a connection that has negotiated h2 via ALPN. net/http then writes HTTP/1.1 onto it and the first response fails to parse:

net/http: HTTP/1.x transport connection broken: malformed HTTP response
"\x00\x00$\x04\x00\x00\x00\x00\x00\x00\x05\x00\x10..."

which is an HTTP/2 SETTINGS frame.

Changes

1. ALPN Selection:

   • Adds ClientOptions.NextProtos (applied when a client tls.Config is built via NewS2ADialTLSContextFunc and NewTLSClientConfigFactory).
   • Adds TLSClientConfigOptions.NextProtos as a per-Build() override.
   • Falls back to {"h2"} when unset, and strictly enforces HTTP/2 for gRPC client handshakes.

2. Addressed Review Feedback from Allow clients to select ALPN protocols instead of forcing HTTP/2 #159:

   • Replaced manual slice append with slices.Clone(nextProtos) in internal/v2/tlsconfigstore/tlsconfigstore.go.
   • Cleaned up doc comment on nextProtosOrDefault.
   • Added unit tests for NewTLSClientConfigFactory with custom NextProtos in s2a_test.go.
   • Added end-to-end HTTP/1.1 negotiation test in s2a_e2e_test.go.

Co-authored-by: Sruthi Talluri sruthitalluri@google.com

[rmehta19]

Can we manually E2E test this? We have an example folder in the top level directory which may contain some useful components for testing

[anushka567]

Thanks @rmehta19, addressed the nits. I ran a manual E2E with every component as a separate OS process: the standalone fake S2A , a plain crypto/tls + net/http server offering ALPN [h2, http/1.1], and a small client using only the public s2a package (NewS2ADialTLSContextFunc). Testing details:

• main (fe5acd2), default options: server saw ALPN offer [h2]; client failed with malformed HTTP response (the bug this PR fixes).
• PR (f59ab3d), default options: identical result, so the default is unchanged.
• PR with NextProtos: []string{"http/1.1"}: server saw offer [http/1.1]; 200 OK, resp.Proto=HTTP/1.1, negotiated http/1.1.

gRPC: I couldn't wire example/client , example/server to the fake as-is. None of the three binaries call flag.Parse(), so --port, --s2a_addr are ignored and the defaults don't line up (fake :8008 vs examples 0.0.0.0:61365). The gRPC path is still covered by the existing e2e tests (e.g. TestV2EndToEndUsingFakeS2AOverTCP).