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.

RPL_ENDOFWHO should send the original, un-normalized mask

Improve documentation for use of certificate fingerprints

Reported by @Mikaela; normally this requires +o or higher on the
channel that is the target of the forward, but SAMODE should bypass
this check.

It was sending MESSAGE_ERROR, which was inappropriate. Send an empty batch
for now (this is at parity with the in-memory implementation).

Reported by @mogad0n. If a user had both operator privileges and
channel owner privileges, the CS TRANSFER would proceed as though
unprivileged, requiring acceptance by the receiving user. Fix this
to not require acceptance.

Reported by @tacerus. This was most likely introduced by 8b2f6de3e.

Add a config option to suppress LUSERS

See #1676

Ensure the pagination window is full by making sure that every history item
gets a replay line in CHATHISTORY output, even TAGMSG.

This reverts commit 5bbee02fe6.

Fix various pagination issues with CHATHISTORY; also undo #491
(msgid munging).

Fixes #1787

Partially fixes #1679, not sure whether to police the relaymsg config or not

Warn if the user sent, e.g., /QUOTE /SAMODE instead of /QUOTE SAMODE

RPL_WHOISACTUALLY should display some arbitrarily chosen IP address and
hostname.

* Add email-based password reset

Fixes #734

* rename SETPASS to RESETPASS

* review fixes

* abuse mitigations

* SENDPASS and RESETPASS should both touch the client login throttle
* Produce a logline and a sno on SENDPASS (since it actually sends an email)

* don't re-retrieve the settings value

* add email confirmation for NS SET EMAIL

* smtp: if require-tls is disabled, don't validate server cert

* review fixes

* remove cooldown for NS SET EMAIL

If you accidentally set the wrong address, the cooldown would prevent you
from fixing your mistake. Since we touch the registration throttle anyway,
this shouldn't present more of an abuse concern than registration itself.