wRPC transport "upgrade"

[rvolosatovs]

Currently NATS transport uses "handshake" procedure to establish a two-way, point-to-point communication channel, it achieves this by setting up two NATS inboxes, one per peer. That is done, because there's no way to know if the peer is reachable by any other means than via the NATS broker. This works great for a single message exchange. However, in async scenarios or when payloads are large and do not fit in a single message, it would be great to have a way to negotiate a more efficient communication channel after the initial exchange. This basically means that we could conveniently do service discovery over NATS and then switch to a more efficient channel for actual data transfer.

Keeping the "0-rtt"-esque semantics of existing NATS transport, the way that a NATS -> QUIC upgrade could work is:

1. Client sends the (potentially truncated) parameter payload to $prefix.foo.bar. If the client is reachable on a particular UDP endpoint, it could send that endpoint as the "reply" header. (the "reply" header should probably be an ordered list containing the NATS inbox as the "fallback")
2. If the client's UDP endpoint is reachable by the server, it could reply directly on that endpoint. If not - it would just fall back to NATS. Similarly to the client, the server could now communicate the ordered list of endpoints that it would listen on.
3. Client continues data transfer over the more efficient transport, if the endpoint is reachable and otherwise falls back to NATS. In case of QUIC, it could also simply use the connection established by the server if the client communicated a UDP endpoint to the server

This way we could eliminate the middleman (NATS) allowing for efficient data transfer without sacrificing the ease of service discovery that NATS gives us.

This mechanism does not seem to be specific to NATS, but seems to be beneficial for any transport, which relies on some kind of broker service in the middle