Prior to this, m_ison would report a nick as being online if a client
that was not yet registered had chosen this nickname on the same server.
This change adds a check to make sure the struct Client has a
struct User associated with it, i.e. registration has occurred.
The existing approach to invite-notify is deeply flawed--it currently
notifies only the target user's server, and that can't be fixed without
sending notifies for invites that end up not happening.
I'm resolving this by broadcasting a second message, INVITED, from the
target user's server. I'm also pulling it out into an extension while
I'm at it--invite notifies reveal new information, so I don't think
they should be mandatory.
/modrestart used to be implemented as a normal command and could crash
when used remotely because it would reload m_encap, which was on the
call stack at the time. This was fixed in 41390bfe5f. However,
/modreload has exactly the same problem, so I'm giving it the
same treatment.
Incidentally: This bug was first discovered in ircd-seven, where the
`/mod*` commands themselves live in the core, so m_encap was the only way
the crash could happen (and it didn't most of the time, because m_encap
would only be moved if you got unlucky). But `/mod*` are in modules in
charybdis, so /modrestart would have unloaded the code it was in the
middle of executing. With that in mind, I'm not sure how it ever
appeared to work.
Charybdis' rewritten m_grant introduces at least one serious bug without
providing any apparent benefit. I think the best solution here is the
easiest one.
The bug in question is that an empty mode change is triggered after
seven's grant has done its work, and this is necessary in order to
give umodes granted by oper privileges a chance to update. The rewrite
removes this, generating a mode change only if it wants to change the
state of +o, which means the grant victim can keep privileged modes they
no longer have access to, or fail to gain new ones.
