Client: multiplex connection data streams

[octol]

Description

Closes: #1939
Part of: #1960

Transmission lanes

Introduces the concept of TransmissionLanes in client-core.

pub enum TransmissionLane {
    General,
    Reply,
    Retransmission,
    Control,
    ConnectionId(ConnectionId),
}

The idea is that the OutQueueControl will multiplex sphinx packets according to these categories. Large data transfers will not block other connections, and smaller messages will be given priority.

Tagging messages

The SOCKS5 client will tag sent messages accordingly, and is relatively straightforward as it owns the whole pipeline from incoming TCP connection to transmitting sphinx packets to the gateway via the gateway-client.

The network-requester however, will need to modify ClientRequest to append a connection_id to ClientRequest::Send, as well as add another message type, ClientRequest::CloseConnection(..).

Connection handling in the OutQueueControl

Because there might be a not insignificant delay between accepting TCP connections and transmitting the sphinx packets, depending on load, the OutQueueControl needs to be able to discard packets destined for a stale and closed connection.

Message priority in OutQueueControl

Initially a very rudimentary heuristic is used to prioritize packets in the OutQueueControl, where small packets will be sent first.

Testing

Confirmed in keybase that:

1. sending a large video in keybase at the same time as
2. doing a ping with curl --socks5-hostname localhost:1080 https://nymtech.net/.wellknown/connect/healthcheck.json
   does not affect each other (too much)

TODO

• Multiplex outgoing connections in nym-socks5-client
• Multiplex outgoing connections originating from nym-network-requester
• We need a way to signal that closed or stale connections should be removed from the out queue controller
• Better packet prioritization. Let small packets through.

Checklist:

• added a changelog entry to CHANGELOG.md