Do kick_on_split_riding if services sends an SJOIN
with a lower TS and a different key. This relies on
services restoring TS (changets option in atheme) and
services not immediately parting after receiving the
KICK, which is the case in recent atheme.
For invite-only channels, still only do
kick_on_split_riding in netbursts. Services is
assumed to handle this itself (atheme does).
Any hunted parameter with wildcards is now assumed
to be a server, never a user.
Reasons:
* fewer match() calls
* do not disclose existing nicknames
* more intuitive behaviour for CONNECT
m_trace has a copy of some hunt_server logic in it
(for the RPL_TRACELINK reply), so adjust that too.
The extended-join client capability extends the JOIN message with information clients typically
query using WHO including accountname, signon TS and realname.
The reason why we do this is because some clients are dependent on receiving a numeric
for every channel join failure, even due to this limit where it can be assumed that
subsequent joins failed.
This has a separate enabling option channel::channel_target_change.
It applies to PRIVMSG, NOTICE and TOPIC by unvoiced unopped non-opers.
The same slots are used for channels and users.
The code behind this capability was never implemented, and subsequent
discussions have agreed to approach the problem differently. There seems no
reason to continue advertising a capability that does nothing.
* does not apply to NOTICE (as those may well be automated)
* mirrors +g behaviour so that no useless accept entries are added for services
* respects max_accept, if it would be exceeded the message is dropped with numeric 494
* check moved up so this is checked before floodcount/tgchange
This shouldn't provide any way for a client to get on a CALLERID list
without authorization, as if a client is +g already, a CTCP request, for
example, won't be replied to.
(resv, cmode +m, cmode +b, cmode +q, etc.).
This is only checked for local users.
For optimal compatibility, a failure for this reason still
returns ERR_CHANOPRIVSNEEDED.
Side effect: normal users cannot change topics of resv'ed
channels, even if they have ops, just like they already
cannot send messages. This only matters if resv_forcepart
is disabled, as the user would have been removed from the
channel otherwise.
