Closes #6

When running psql commands to insert rows in the database, psql normally
returns an message about what it did, eg "INSERT 0 1" if it inserted a
row. This can be suppressed with -q . Several of the scripts use psql
commands to get primary keys from the database, inserting the row if
necessary. This can lead to the host id variable in the script being set
to 'INSERT 0 1 <thehostid>' which causes problems when this variable is
used in other SQL commands.

This always used to work; I suspect the thing that changed is our
upgrading to Postgres 16 on the backup servers, but I'm struggling to
see how as Postgres 13 seems to behave the same for me.

I think the intention here was perhaps:

- create new host, marked as disabled
- finish setting up backups
- once done, mark host as enabled

...except the script runs as "set -e", so if something goes wrong
we just never get as far as enabling the host, which means not only
do no backups run but no failure reports get sent to xymon so we
don't even notice the failure. This is not good.

Given the entry of a row in the `host` table doesn't do much in and
of itself, I see no reason why we shouldn't just mark the host as
initially enabled. We won't try to actually perform a backup until
a `backup_task` has been created. Perhaps this leads to a brief
transient behaviour where xymon reports a backup as failing whilst
the script is still running - but OTOH the xymon report for a new
machine will always be red for "a while" until the first backup
has actually run OK.

We don't need to record the ssh host key in most cases given that we
generally deploy signed ssh host keys, but I suspect we might have the
occasional backup target where that doesn't apply (e.g. clusters?)

Regardless, if we can't scan the host key the right behaviour is for
the script to continue on and set up the backup. If the backup then
fails due to the absent host key, we will be alerted and take suitable
action. Right now, the failure mechanism is that we silently don't finish
setting up the backup, the backup never gets enabled, and we don't
realise we don't have a backup - eek.

These are static files provided by our package, not config files.

https://tickets.ch.cam.ac.uk/rt/Ticket/Display.html?id=211460

e.g. RT 211460, 211465. spri-musuem-rt-2025 had been set up with an adhoc script
which was not properly tidying up after itself due to bailing early on a "set -e"
error.

I don't think there's a sensible default quota; the value for
a workstation will be very different to a tiny VM, for example.

This is needed on focal if a client is to be able to access snapshots over NFS.
From the docs I don't see why we didn't also need this option on xenial,
but empirically, we need it on focal. (e.g. RT-207229)

We now e.g. have a cron job on cerebro-backup which calls
these scripts, where /sbin is not on the $PATH.

The new-backup-rsnapshot script understands a 'postgres' argument, but
this set up a postgres backup in an old style that we no longer use.
This change updates it to do some of the work of setting up a new style
postgres backup and tell the user what else they might need to edit to
make it go; it varies quite a lot depending on server.

Forcing arcfour causes us not to be able to back up jessie machines.