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".

LIST should not return ERR_NOSUCHCHANNEL for nonexistent channels

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).

* Fix #1911 +s channels don't appear in /list even though on the channel

* use channel.HasClient instead of custom iterative checker

Include server start time in INFO output.

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.

Don't allow any new uses of 0 as a nickname, since it conflicts with
the use of 0 as a placeholder for account name in WHOX.

AMODE +v should allow you to join a +i channel

NS SAREGISTER would fail due to a nil dereference of `client`;
add two safeguards against this.

This extends #1650 to cover WHO as well as WHOIS

See discussion on #1891

* optionally protect against multiple starts with flock

Fixes #1823

* use traditional .lock extension

* move config key to top level

INVITE did not exempt from +b unless the channel was coincidentally also +i.
This was a regression introduced in v2.4.0.

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.

See #1858: this was the intent all along, but I missed this issue.

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.

This should have been done in 8b2f6de3e0, since we updated both
the database schema and the importer then.

Jobe points out that 0 is a valid oplevel in some contexts,
* is a better placeholder for "unimplemented".

CS AMODE changes should take immediate effect even if the nick
does not match the account.

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

It collides with the massmessage mask syntax. Reported by @emersion

See discussion on #1852

From discussion with @emersion, this will help with UX if people try to
log into their unverified accounts.

Warn about banning a single IPv6 address

Account registrations pending verification should produce a logline and
send a sno.

CS PURGE should send a snomask

Send snomasks for HS SET

Reported by @mogad0n; the mute mask was being case-canonicalized,
but the RELAYMSG identifier wasn't being case-canonicalized before
the check.

`WHO #channel o` is supposed to return only server operators.
This is RFC1459 cruft; just return an empty list in this case.