Fast connections

[tbraun96]

When UDP NAT traversal is implicated in the connection process, the entire connection is blocked, even if messages could pass through via the active c2s connection or the relayed p2p connection. The protocol should allow instant relaying of messages once both peers decide to begin connecting to each other. Once NAT traversal completes, the protocol should automatically begin using the direct p2p connection over the relayed connection, only using the relay as a back up.

[tbraun96]

For C2S connections: instead of waiting for UDP hole-punching to complete, spawn the UDP hole-punching in another task, and immediately begin the following stage. Also, since the UDP receiver from the kernel-application side is async, once UDP hole-punching is done, the channel can be sent over. Some modifications to the BEGIN_CONNECT stage will need to be done.

For P2P connections: all P2P requires QUIC, which requires UDP, which requires UDP hole-punching. We can still spawn this process in another task, then, send the P2P channel immediately to the kernel-application which will automatically choose relaying via the server to facilitate communication. We can add a flag to the POST_CONNECT stage that allows peers to disable this behaviour (useful for unit tests).