Exchange muxer info in security handshake

[MarcoPolo]

We can save one round trip by passing in supported muxers in the security handshake. This isn't multi stream select v2 or protocol select (but can use similar ideas).

This can be a small incremental upgrade that reduces our round trip setup cost by one.

We can define a code for each muxer and exchange a list of which codes are supported in the handshake, and the responder can respond with their preferred muxer in the handshake response.

cc @marten-seemann since this came from a discussion we had. Please feel free to fill in any details I missed.

[marten-seemann]

TLS can use ALPN, in Noise we can use early data, similar to what we do in the WebTransport handshake.

One thing to keep in mind is that this data is sent in the clear. Not a problem for Noise, but it is for TLS, if you're trying to hide your traffic among web traffic. To be clear, we don't do this today, we're currently using "libp2p". One way out of this might be using ECH, but it's unclear if there'll be a Go implementation in crypto/tls.

[mxinden]

This isn't multi stream select v2 or protocol select (but can use similar ideas).

This could just be a Protocol Select message, no? In other words, from Protocol Select perspective, this would just be an early data mechanism (see #349 "Early data optimization"), right?

[marten-seemann]

I don't think we have to specify the format of this message for all security protocols. The encoding will likely be specific for the security protocol. What we can do is spec the mechanism.

For example, for TLS we're limited to strings (at least in Go, see NextProtos of the tls.Config: https://pkg.go.dev/crypto/tls#Config), although RFC 7301 allows byte strings. For Noise, we have more flexibility in defining the format of the message.

[BigLep]

Spec change: #446