Don't mention the client ID before the ID is known. No functional
change, just logging cleanup.

Interminnent merge, to bring an improvement of the fwup plugin master
for easy deploy (as this plugin is not out in the wild yet, there's
nothing that would break by this merge).

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.

Use a table & view to fill it with data instead of materialized view. It
is similar in principle, but the table allows us to specify indices and
updates concurrently, instead of locking the whole table.

Wait until the DB starts accepting connections if it doesn't work at the
beginning. Blocking.

Detect when a database connection dies and reinitialize it.

As it is supposed to be faster by dropping it, it shall release some
resources in the server.

Recover from lost DB connection. Initialize a new one.