We were ending the flood grace period for any channel mode command other
than `MODE #foo [bq]` by means of a hardcoded check. I've moved that to
after we parse the mode string, so we can correctly identify all
requests to change modes and end the grace period on exactly those.
It would have been entirely possible to move the check even further down
and flood_endgrace on only mode commands that *actually* change modes,
but I don't like the idea of making it sensitive to external conditions.
Also fix up some return values and stuff to use bool (or void if
nothing). I just did it whilst I was here.
According to jilles, the return value used to signify whether or not the
client had exited. This was error-prone and was fixed a long, long time
ago, but the return value was left int for historical reasons.
Since the return type is not used (and has no clear use case anyway),
it's safe to just get rid of it.
Charybdis requires C99 already, so it's high time we start using
stdbool. I've converted a few pieces of code already.
A lot of the old code that uses YES/NO should probably be updated too
because that's fucking hideous.
Arbitrarily prefer a forward channel to no forward channel and an
alphabetically higher forward channel to a lower one.
This is a simplistic implementation that generates one MODE message to
local clients for each ban removed (to be replaced).
For simplicity and to avoid amplification of incoming MODE messages,
regular modes may still desync the forward channel of a ban.
If a netburst adds bans or a channel TS change removes bans, +b/-b modes
are generated. Make sure these contain the forward channel, if any.
This appears also broken in ircd-seven.
nenolod gave the thumbs-up to port ircd-seven banfowards to charybdis to spb
for a while, and people have asked about it. Might as well do it since it's a
slow weekend.
Note that as a side effect use_forward is removed from the config and
unconditionally enabled!
Special modes like +j can be tracked easily just by adding the necessary
code to parse them to set_channel_mlock(). This will cover propagation
as well.
This check sometimes blocks oper overrides (OMODE).
It does not stop any hacks that the channelTS check
already stops, because CHFL_DEOPPED is only set when
this server ignored an @ in an incoming SJOIN (the
SJOIN is then propagated without the @) and this
can only be because of a TS difference.
