Move opername and privset storage to struct User, so it can exist for
remote opers.
On /oper and when bursting opers, send:
:foo OPER opername privset
which sets foo's opername and privset. The contents of the privset on
remote servers come from the remote server's config, so the potential
for confusion exists if these do not match.
If an oper's privset does not exist on a server that sees it, it will
complain, but create a placeholder privset. If the privset is created by
a rehash, this will be reflected properly.
/privs is udpated to take an optional argument, the server to query, and
is now local by default:
/privs [[nick_or_server] nick]
It's possible to have the oper:override privilege removed by /grant.
/grant triggers an empty umode change event to allow privileged umodes
to be set or removed, so checking for oper:override on all umode changes
(and not just ones where +o or +p is changed) allows us to remove +p
when necessary.
Reloading override previously would have the effect of cancelling +p
expiry. With this change, reloading the module just refreshes the
timers, so expiry is delayed a bit rather than forgotten entirely.
construct_umodebuf() can change the char->flag mapping (to restore an
orphaned mode). I don't love the use of a fake constant, so I think the
cleanest solution here is just to index user_modes with a macro for the
umode letter.
This change modifies extb_channel to allow matching users in secret
channels, which prevents trivial ban evasion by setting the target
channel +s. Information leak due to this change is unlikely since the
attacker would have to know that the target channel exists, the name of
the channel (or guess it), have a specific user they wanted to know
whether was in the channel (and not know already), and the target user
would need to have something like autojoin-on-invite enabled (or any of
the other various ways hostname cloaking is attacked).
