The firewall rules use names ending with _X, the plain ones are the
temporary sets.

And try to make the chance of reaching the ipset max name length limit
(31 chars) smaller. We actually hit the limit in practice.

Make the timeout for reload of the sets longer. In case there's some
serious problem (like kmod-ipset not loaded), it wouldn't clutter logs
this way, but if it is recoverable, it'd recover after relatively short
time anyway.

Update the state field of sets when updates come. While not updating it
was mostly harmless, this optimises out some downloading of data and
some passing of data to kernel. And it was the original intention.

When the set size is being changed, it is not needed to remove the set
from kernel and create it again. And it wouldn't even work in case the
ipset is already linked into the firewall.

Simply reloading the content by swapping with a newly created set is OK.

Grant the script permissions to update the sets' data in database.

Generate the firewall sets' content. Handle growing of sizes.

Keeping of still active but blocked IPs is still planned.

Take some functionality that'll be reused in other scripts and put it to
separate library. The purpose is more code sharing than some
general-purpose library.

Configure the hash sizes of the sets in addition to maximum number of
elements. Added to the DB, the master, docs and the plugin.

Also, fixed a copy-pasted log message on the way.

Insert the right name into the known_plugins table when debug mode is
requested.

Check against duplicate addresses (added twice in a row or removed twice
in a row).

Fix after 60bef82d.

The count of activities per day may overflow the smallint because of
still deployed bug in fake log submission buffering. Increase the data
type size accordingly.

Don't let the client wait too long when it reconnects because of a
broken connection.

Don't allocate additional memory in the trie if we are over the limit.

After reconnecting, either ignore the config update (if the config is
the same we have) or wipe out the old config first to free the memory.

Don't let the client wait too long when it reconnects because of a
broken connection.

Don't allocate additional memory in the trie if we are over the limit.

After reconnecting, either ignore the config update (if the config is
the same we have) or wipe out the old config first to free the memory.

Otherwise, the errors might be overwritten or some other bad things may
happen.

We are using features of API version 2, so don't forget to increase it.

Call a plugin's callback whenever a child terminates. Increases the API
version, as there's an added callback in the structure.

If we mark them as explicitly rejected or dropped by an IPset from the
server-side blacklists, then don't let it in. We don't need to test if
the IP is attacker, we already know that.

Use „Fwup“, as this is automagically deduced by some auxiliary scripts.
It is easier than hacking all these scripts.

This situation is rare, but actually can happen, because the client may
reconnect/restart or join the group before it received the config. Just
warn in such case instead of crashing and ignore the request (the server
will be OK if it doesn't get the answer, it waits for a timeout anyway).

When there's an exception during a looping call, don't abort future
calls of the callback. In case of database error or something, we want
to continue operating with the next attempt.

They help only a very little, but slow down the cache computation a lot.

Since TRUNCATE has the same problems as REFRESH MATERIALIZED VIEW.