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.

Disable the old connection without compression. It is no longer used, so
don't sit on the port.

Use diff_addr_store.py in the master flow plugin, to share the same code
with FWUp to handle updating the address sets.

Don't leave old values in the sets when the plugin starts and does a
full update. They might be gone by now, so do a full replace of the set.

Use socketpair to talk with the ipset command instead of pipe. For one,
we couldn't use send with pipe. For another, we are able to log its
output and see if something went wrong.

Use the new variadic functions for parsing & rendering of data, making
the code shorter in the process.

They allow to parse/render multiple elements at once, doing all the
necessary size checks.

Use it so the error messages are sent to the server.