Goal

• As a firewalld admin, I want that reloading firewalld always removes the old firewalld table placeholders using separate calls, so that reloading doesn't crash when one/some/all of the firewalld tables don't exist.

Acceptance Criteria

• Start firewalld: `systemctl start firewalld`
• Remove one of the firewalld tables externally: `nft delete table ip6 firewalld`
• Reload firewalld: `systemctl reload firewalld`
• Reloading doesn't fail and the firewalld tables are restored.

Background

Currently a firewalld reload seems to generate two transactions when IndividualCalls=no:

   a) delete old tables + build new ones:

{"nftables": [{"metainfo": {"json_schema_version": 1}},
  {"delete": {"table": {"family": "inet", "name": "firewalld"}}},
  {"delete": {"table": {"family": "ip", "name": "firewalld"}}},
  {"delete": {"table": {"family": "ip6", "name": "firewalld"}}},
  {"add": {"table": {"family": "inet", "name": "firewalld"}}},
  {"add": {"table": {"family": "ip", "name": "firewalld"}}},
  {"add": {"table": {"family": "ip6", "name": "firewalld"}}}]}

   b) Add chains and ruleset

{"nftables": [{"metainfo": {"json_schema_version": 1}},
   {"add": {"chain": {"family": "inet", "table": "firewalld", "name": "filter_IN_public"}}}, 
 [...]

If the firewalld tables have been removed externally (I know, this shouldn't happen, but might happen actually), then the first transaction will fail, the following error is printed

ERROR: 'python-nftables' failed: internal:0:0-0: Error: No such file or directory; did you mean table ‘firewalld’ in family inet?

and the second transaction (adding chains + ruleset) will fail as well as the tables don't exist

ERROR: 'python-nftables' failed: internal:0:0-0: Error: No such file or directory 

Additionally, the temporary `policy_drop` table will remain installed.

I'm not sure if this behavior is on purpose, in order to somehow guarantee that "reloading" is actually reloading the contents of the firewalld tables. and they have not been modified externally.

Either way, given that this scenario currently leaves the system with a drop-everything-not-established policy installed, it would be useful if firewalld doesn't really care about whether the firewalld tables existed previously when a reload is issued, and it just tries to make sure that the required tables exist before adding the chains/ruleset.

If the transaction is separated into two separate ones:

   1.- delete old tables

   2.- add new tables

Still failing to delete one of the old tables might leave the other tables installed with their previous ruleset contents, so I think that a safe approach would be:

   1.- Delete old tables, one by one

   2.- Add new tables

   3.- Add new chains and ruleset

I'm not sure about the performance penalty that this change would introduce. Clearly much less than having IndividualCalls=yes.