Forwarding mode cannot work reliably as currently defined

[DavidSchinazi]

Forwarding mode works by having the proxy demultiplex incoming packets by looking at the Destination Connection ID field in short headers: if it's a registered "Server Connection ID", it gets forwarded to the target; otherwise, it gets processed as a QUIC packet intended for the proxy itself.

Unfortunately, Server Connection IDs are not under the control of the proxy, they're under the control of the target(s). So that means that there can easily be conflicts. The fact that short header packets do not carry the connection ID length complicates this further: any connection being a prefix of another one also constitutes a conflict. In the worse case scenario, a single target using zero-length connection IDs would conflict with all other Server Connection IDs.

In #17 and #18, a proposed solution is to reject CONNECT-QUIC requests whose Server Connection IDs conflict with existing mappings. This would mean that this protocol would be completely unable to handle a set of targets, which would be unfortunate.

However, we could solve this issue by making the forwarding mode negotiable. Here's a straw man: the client adds a Forwarding-Mode: 0/1 header to its request to tell the proxy whether it wants forwarding mode for this request or not, and the proxy replies with the same header to indicate whether forwarding mode is allowed for this request. That way, if the server detects a conflict, it gracefully falls back to tunneled mode and everything still works. (Bonus 1: this also allows us to support proxies behind load balancers, they just need to disable forwarding) (Bonus 2: this also allows us to support the MASQUE Obfuscation use-case by letting the client disable forwarding)

[tfpauly]

Yeah, I was expecting that a forwarding mapping failing would mean we'd have to fall back to tunneled mode anyhow. I'll specify this more clearly, as it is the intent.

[tfpauly]

Addressed by #24