`NICK :` pre-registration needs to be special-cased to immediately
send ERR_NONICKNAMEGIVEN (unlike erroneous nonempty nicknames,
which are processed when registration is complete)
If the nickname must equal the account name (because always-on or
force-nick-equals-account), the correct error response to an empty
or otherwise invalid nickname is the usual "You must use your account
name as your nickname".
DEFCON 4 and lower were blocking SAREGISTER. This is wrong; admins should be
allowed to make new accounts even under DEFCON (this may be needed
specifically to work around the DEFCON restriction).
Having the 'samode' capability made all KICK commands privileged. This appears
to have been introduced unintentionally by 42316bc04f and I can't find
any discussion of a rationale. Since this goes against our policy that all
ircop (as opposed to channel founder) privileges must be invoked explicitly
(e.g. SAJOIN, SAMODE), remove this.
correctly account for nickname in CAP LS arithmetic
The arithmetic was assuming that the nickname is * (which it is
pre-registration). However, we were sending the actual nickname
post-registration. It would be simpler to always send *, but it
appears that the nickname is actually required by the spec:
>Replies from the server must [sic] contain the client identifier name or
>asterisk if one is not yet available.
There is no change in behavior since committing the transaction
already write(2)'s all the data to disk. But let's comply with
the official buntdb API.
The channel mode +R used to both prevent joins by unregistered users,
and prevent unregistered users who happened to be joined from speaking.
This changes the behavior so that +R only prevents joins:
1. This allows users who were invited or SAJOIN'ed to speak
2. To restore the old semantics, chanops can set +RM