This skips several tasks that fail, at least in some conditions, when
run in check mode but not when run in normal mode.

As I noted in an earlier commit, restricting Docker's ingress traffic is
more complicated than adding a few rules to the filter table's INPUT
chain. I had thought that relying on LOCKSS's "LOCKSS_ACCESS_SUBNET"
variable would be sufficient; unfortunately, that is not the case:
LOCKSS sees all of its traffic as coming from the Docker overlay network
(by default, 10.0.0.0/8), regardless of its true origin.

Fortunately for us, Docker provides us with a chain, DOCKER-USER, called
by Docker's rules from the FORWARD chain in the filter table, that is
suitable for filtering Docker's ingress traffic.

Accordingly, this commit:

- Removes the misleadingly ineffective 'lockss_trusted_ips' variable and
  provides new variables 'lockss_network_ips' and 'lockss_admin_ips'.

- Replaces ufw or firewalld with ferm. Neither ufw nor firewalld is
  capable of satisfying this use case without employing significant
  violence; ferm is elegant and has beautiful configuration files.
  Beauty over bloodshed.

- Adds tasks to configure a local firewall that denies inbound and
  forwarded traffic by default, permits ssh from anywhere, and permits
  access to LOCKSS's data and configuration ports from
  'lockss_network_ips' and 'lockss_admin_ips' respectively.

  Said firewall cooperates with Docker: Docker and the firewall can be
  started in any order, and restarting either preserves rules created by
  the other.

                                *  *  *

I got the suggestion of using ferm for this, as well as the bulk of the
Docker-related rules, from a blog post: Ben Chavet, Convincing Docker
and Iptables to Play Nicely, Aug. 8, 2019,
<https://www.lullabot.com/articles/convincing-docker-and-iptables-play-nicely>.

This reduces the time and space required to spin up a new VM.

I see little risk in using known passwords here, but it's such a bad
practice that I'd rather avoid it entirely.

(The worst case I can imagine is that a malicious process running on the
developer's workstation would be able to manipulate the configuration.)

Docker secrets cannot be changed (at least through the Ansible module)
while their are in use.

This breaks idempotency.

Ordinary firewall filtering rules, placed in iptables's "INPUT" chain in
the "filter" table, aren't applied to Docker's ingress traffic, which is
redirected ("NATted") to Docker's interface by the "PREROUTING" chain in
the "nat" table. Hence, the rules pretending to allow LOCKSS management
traffic from trusted hosts are superfluous and misleading: traffic to
those ports is instead restricted by LOCKSS according to its
"LOCKSS_ACCESS_SUBNET" variable.

I could write rules to filter Docker's ingress traffic, but I would
rather not take the time--I would need to take care that they were
always given priority over Docker's rules, even when Docker were
restarted--and LOCKSS's own handling of matters ought to be sufficient
for now.

With that, the base firewall rules (enabling a default-deny ingress
policy with an exception for ssh) seem out of scope for this role.

- Vagrantfile: Correct the path to the parsed YAML file. (This caused
  'vagrant global-status' to fail when called from outside the project's
  directory.)

- Vagrantfile: As we do not use it, disable the default sharing of the
  project's directory with the VMs.

- lockss: Use /tmp as temporary directory.

- Other trivialities.

When it already exists, the swap file managed by the role must be
excluded from the sum of memory and swap used to calculate the size of
said file.

The size of the swap file's header ought to be included in the
calculation; otherwise, the file will be slightly undersized, and the
role will re-create it at every invocation.