client communication of target-provided stateless reset token

[ehaydenr]

Addresses #48, however, instead of converting stateless reset packets to a stream error, they are simply tunneled or forwarded to the client.

A couple questions come to mind:

Should receipt of a stateless reset packet result in a stream error?

• Offers reliably delivered signal to the client that the connection is broken.
• Allows the proxy to terminate the stream immediately and avoid having to consider handling of many stateless reset packets
• What H3 error code? H3_CONNECT_ERROR?

If not a stream error, is tunneled OR forwarded OK?

• If we require they be tunneled, does that make things easier for the client at no cost to the proxy?
• Is there any reason why we wouldn't want the stateless reset packet sent "in the clear" (forwarded)?

[tfpauly]

I lean towards forwarding the stateless reset, rather than making this a stream error. That’s effectively what the PR does, right?

[ehaydenr]

That’s effectively what the PR does, right?

Yes, that was the intention. It also allows for either tunneled or forwarded. That seemed like the least prescriptive, but I can also see an argument for restricting it only being sent via the tunnel instead of being forwarded.

[tfpauly]

Yeah I could see that it might interfere with forwarding. Saying that it only tunnels would be a bit simpler. Only short header packets get forwarded, and this arguably doesn't meet that bar.