This fixes a serious bug where we stop executing forEachDownstream on
the first downstream that does not match the network. Instead we want to
simply continue; it's a basic filter.
On upstreams without message-tags support, we do not advertise
message-tags anymore. Still, we want to send the batch tag when the
client explicitly requested it.
This fixes a critical issue where we drop the batch tag on chathistory
messages for upstreams that do not support message-tags.
Previously, we would always advertise mesasge-tags. This made
downstreams believe they could send TAGMSG to the upstream, even though
the upstream did not support it.
This adds support for upstream echo-message. This capability is
enabled when the upstream supports labeled-response.
When it is enabled, we don't echo downstream messages in the downstream
handler, but rather wait for the upstream to echo it, to produce it to
downstreams.
When it is disabled, we keep the same behaviour as before: produce the
message to all downstreams as soon as it is received from the
downstream.
In other words, the main functional difference is that when the upstream
supports labeled-response, the client will now receive an echo for its
messages when the server acknowledges them, rather than when soju acks
them.
Additionally, uc.produce was refactored to take an ID rather than a
downstream.
When a client sends BOUNCER CHANGENETWORK with no value (or an empty
port value), this means it wants to reset the port value to its default
value.
Previously we considered an empty port as an actual valid, empty port
value, which would then be used to connect to the server (dial
'example.com:' (ie 'example.com:0'), which failed.
This avoids having more than one in flight at a time (avoids
hitting rate limits a bit) and routes back replies to the correct
downstream connection (even if labeled-response isn't supported).
Closes: https://todo.sr.ht/~emersion/soju/193
Per the spec:
> If the source is missing from a message, it’s is assumed to have originated
> from the client/server on the other end of the connection the message was
> received on.
