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
Just force-set the nickname and completely disregard what the client
sets during connection registration. Clients must discover their
effective nickname via RPL_WELCOME.
Most users will connect to their server with `<username>` as their
username in order to configure their upstreams.
Multi-upstream can be unintuitive to them and should not be enabled on
that first connection that is usually used for upstream configuration.
Multi-upstream is instead a power-user feature that should be explicitly
enabled with a specific network suffix.
We reserve the network suffix `*` and use it a special case to mean that
it requests multi-upstream mode.
Previously, when we sent READ for an upstream which was disconnected,
we would fail with an error. This is because we called unmarshalEntity,
which checked that the upstream was in the connected status.
But we don't need to be connected to update the READ timestamp, this is
a purely offline (wrt the upstream) operation.
This simply switches the call from unmarshalEntity to
unmarshalEntityNetwork to fix the issue.
