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.
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.
Currently, if we fail connecting to a new networking during welcome, we
send no error message to the client, and the connection remains open in
an undefined state.
Given the input:
NICK nick
USER user/invalid.xyz s e r
PASS pass
soju will fail to connect, add a message to its own logs, but will
return no message to the downstream.
This fixes the issue by forwarding the error message if it is an IRC
error message (which it is for connecting to new networks).
We should probably also close the connection after the message is
written, because it leaves the connection in an undefined state. This is
TODO for now because we'd have to wait for the error message to be
written out first, which is non-trivial.
On some systems (namely Windows), syscall.Rlimit is not defined, and
makes the build fail.
This fixes the build by making the rlimit calls only run on archs where
it is defined, defaulting to a stub on other systems.
See: 8427429c59
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.
When the client supports draft/chathistory, no need to request
delivery receipts via PING messages. Let's just not leave delivery
receipts alone. They'll go stale but should be never used (or used
by a non-chathistory client).
