See https://ircv3.net/specs/extensions/capability-negotiation
> Upon receiving either a CAP LS or CAP REQ command during connection
> registration, the server MUST not complete registration until the
> client sends a CAP END command to indicate that capability negotiation
> has ended.
This commit should prevent soju from trying to authenticate the user
prior to having received AUTHENTICATE messages, when the client eagerly
requests capabilities with CAP REQ seeing available capabilities
beforehand with CAP LS.
Since NULL = NULL is always FALSE, this query needs to use IS instead.
This should fix the flood of DeliveryReceipts in the DB.
See https://www.sqlite.org/lang_expr.html
> The IS and IS NOT operators work like = and != except when one or both
> of the operands are NULL. In this case, if both operands are NULL,
> then the IS operator evaluates to 1 (true) and the IS NOT operator
> evaluates to 0 (false). If one operand is NULL and the other is not,
> then the IS operator evaluates to 0 (false) and the IS NOT operator is
> 1 (true). It is not possible for an IS or IS NOT expression to
> evaluate to NULL.
Previously http.Server.ListenAndServeTLS would return a not very helpful
error about a failed open. This adds a check similar to the one in the
ircs case that should make it clearer to operators what the error is.
This allows users to set a default realname used if the per-network
realname isn't set.
A new "user update" command is introduced and can be extended to edit
other user properties and other users in the future.
Typically done via:
/notice $<bouncer> <message>
Or, for a connection not bound to a specific network:
/notice $* <message>
The message is broadcast as BouncerServ, because that's the only
user that can be trusted to belong to the bouncer by users. Any
other prefix would conflict with the upstream network.
The first MOTD upon connection is ignored, but subsequent MOTD messages
(requested by the "MOTD" message from the client, typically using a
/motd command) are forwarded.
