If this option is yes (default), KLINE by itself sets global (propagated) bans.
If this option is no, KLINE by itself sets a local kline following cluster{},
compatible with 3.2 and older versions.
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.
Such bans are not applied locally, but are propagated normally.
They can only be removed on a server that applies them.
Note that normally KLINE will not accept such bans.
This is mainly for services, differing min_wildcard and
ircd changes.
A KLINE command without the ON clause now sets a propagated
("global") ban. KLINE commands with the ON clause work as
before.
Propagated klines can only be removed with an UNKLINE command
without the ON clause, and this removes them everywhere.
In fact, they remain in a deactivated state until the latest
expiry ever used for the mask has passed.
Propagated klines are part of the netburst using a new BAN
message and capab. If such a burst has an effect, both the
server name and the original oper are shown in the server
notice.
No checks whatsoever are done on bursted klines at this time.
The system should be extended to XLINE and RESV later.
There is currently no way to list propagated klines,
but TESTLINE works normally.
When a ban is added or removed, open a transaction and
close it after 3 seconds; any bans in the 3 seconds
will not trigger another transaction (= 4 fsyncs with
sqlite).
The transaction is also committed if ircd closes the
connection, but not if bandb itself is terminated with
a signal.
The value 0 indicates the creation time is unknown (currently the case
for bandb).
Also store a creation time for xlines and resvs, but do not use it yet.
identd and SASL can cause source_p->user to be present without USER having been sent.
Without this change, that could cause a crash later on as localClient->fullcaps is not initialised.