- extract a tempDir() function.

- make the function configurable. In particular, all files created with
  the same prefix is bad, because if we have a left over file on disk,
  it's hard to tell where the file comes from.

It swallows IO exceptions. We often want to just get rid of a file, and
don't bother with a failure to do so.

Most of the time, when the caller constructs a list of rules and
calls set_rules(), the don'tt need the rules anymore. We could
release them from memory earlier, right after set_rules() processed
the list further.

Add an argument "rules_clear" (default to False) to set_rules(). If
true, set_rules() will clear the list after it no longer needs it.
That may allow some memory to be reclaimed early.

…sing rules early

These callers don't actually care about the list that they pass to
set_rules().

By setting rules_clear=True, set_rules() will clear the list after using
it, and thereby potentially already free some objects earlier, that we
don't need anymore.

The point is to reduce spikes in memory, by more eagerly release data
after we no longer need it.

From libnftables we import nftables.nftables.Nftables.
The "nftables.py" module brings a class nftables.nftables.

Don't also call the Nftable attribute self.nftables.

Instead, rename to "self._nft_ctx". The main point is
using a distinct name, so we can grep for it.

We will rework the invocation of the JSON command, by writing the
JSON to file. For that, move the call to self._nft_ctx.json_cmd()
to a new helper.

Note that libnftables' json_cmd() is itself just a small wrapper
around json.dumps() and Nftables.cmd(). As we want to get close
to a place where we don't generate a JSON string in memory, take the
json_cmd() implementation and re-implement it.

Later we will modify it further.

This allows to first `del json_blob` and free the data (if any).
Before we start allocating new data while parsing the JSON response.

Instead of passing the JSON to libnftables, write the JSON to a file in
/run/firewalld, and use cmd_from_file() to load it from there.

The ultimate goal is to reduce the amount of memory we keep around.

Note that the test don't create a separate mount namespace and don't
remount /run. They maybe should do that. But with this change, we
have yet another place where we write temporary files to /run. And if we
run tests in parallel, they could theoretically interfere. In practice
they don't, because the temporary files have unique names. In any case,
if this is a problem, the solution is that tests mount a private
/run/firewalld.

When we configure real rules, we request the handles from the nft call.
Otherwise, that data is not used.

Only request echo output, when we actually use the information.

Previously, when creating an ipset, we would create for each entry a
separate "add" rule, like

    {
      "add": {
        "element": {
          "family": "inet",
          "table": "firewalld",
          "name": "foobar",
          "elem": [
            {
              "prefix": {
                "addr": "10.10.1.1",
                "len": 32
              }
            }
          ]
        }
      }
    },
    {
      "add": {
        "element": {
          "family": "inet",
          "table": "firewalld",
          "name": "foobar",
          "elem": [
            {
              "prefix": {
                "addr": "10.10.1.2",
                "len": 32
              }
            }
          ]
        }
      }
    },
    ...

This is much slowing in libnftables (or kernel) to process, then having all entries
at once. Combine them, now we have:

    {
      "add": {
        "element": {
          "family": "inet",
          "table": "firewalld",
          "name": "foobar",
          "elem": [
            {
              "prefix": {
                "addr": "10.10.1.1",
                "len": 32
              }
            },
            {
              "prefix": {
                "addr": "10.10.1.2",
                "len": 32
              }
            },
            ...

The problem with chunking is that it splits the transaction, and what
should be an atomic update, is not. libnftables is supposed to provide
us with a concept of transactions, if we cannot use that because the
transaction is too large, then that's a fail.

We changed the format of the JSON for ipset entries, instead of an "add"
command for each entry, they are now all combed in one. This
significantly makes the operation faster, and we shouldn't need the
chunking anymore.

This in parts reverts 9a86f11 ('fix(ipset): chunk entries when
restoring set'), however, in the meantime it is thought that the
chunking is no longer necessary.

The JSON data may be large, and we have to convert it to string.
Optimally, we free it as soon as we no longer need it.

Previously, if nft_cmd() failed, we would raise a ValueError() with the
full JSON blob as error message. That means, we had to keep the JSON
blob around for longer. It's questionable whether we really need this.
Note that if you run with  debug logging, then we log the full JSON before
making the call. If we don't have debug logging enabled, then we
shouldn't embed the full JSON data in our error message.

By not embedding the JSON string in the ValueError() after failure, we
can get rid of it earlier.

If we already convert the JSON to string for logging purposes, don't do
it a second time for nft_cmd(). Instead, reuse the string.