New parameter purge_unmanaged_rules to reload nftables if configuration does not match reality

[canihavethisone]

This is a variation on #115, where I use:

• 2 execs
• no script file on disk
• no service file modifications.

Effect:

First install:

• after nftables is installed and configured and service started, a hash of memory state (without counters) is written to disk in the same puppet run

Subsequent runs:
Hash file not present (eg deleted):

1. nftables service is notified to reload
2. hash file is regenerated

Hash of memory state does not match hash on disk (eg rule manually added in memory):

1. nftables service is notified to reload
2. hash file is regenerated

Changes invoked by Puppet to rules:

1. hash file is regenerated (as this module already notifies the service)

Exec time hit
Everyone tries not to use execs, but they work well in this case and over a number of tests I barely saw a 0.1 sec difference, and that wasn't consistent so I think its a good solution.

Thanks for your consideration of this PR!

[bastelfreak]

Please run bundle exec rake strings:generate:reference to update the REFERENCE.md

[canihavethisone]

@bastelfreak
one question I have relates to the choice of location for the hash by the previous PR, which I have copied. Writing it to /run means that upon a reboot the file is missing and will be regenerated, notifying the nftables service to reload unneccesarily. Should this default to a location where the hash file survives a reboot, such as /var/tmp?

Edit: I have pushed this change as it seems logical to avoid a bogus reload of nftables just because the has file doesn't survive reboot.