We had been raising a failure report if we had never seen a succesful backup
for a host. However, when we have a host with more than one backup task, we
can have the situation where one backup is working OK but the other has never
completed correctly. This let to a green report as we had a non-zero number
of rows, but we require number_of_good_backups == number_of_tasks !

This can happen for a number of reasons:

- child ZFS has a quota bigger than its parent
- we have over-provisioned such that the sum of quotas is bigger than the disk
- an individual ZFS has a quota bigger than the disk

..and convert such things to human-friendly versions if required.

This is to facilitate extra checks where we want to make numeric
calculations involving quotas and other similar properties.

This will let us use zfs_target as the name of a subtest which
in turn means we would be able to separately log and graph multiple
backup targets associated with a single host.

This change does not affect the current parsing performed when
we input data into postgres: it uses non-anchored regexps to
identify SpaceUsed etc so prepending extra text won't change
anything

Let's not worry if we haven't backed up a machine that has been offline for 3 months (instead of 6 months)

The script runs some SQL which ultimately determines the time at which the last
backup with an exit code of zero was. If there has never been a successful
backup, we ended up reporting a clear dot. Whilst this may lead to a few
transitory red dots immediately after adding a new host, I think this is
preferable to not realising for months that a host isn't being backed up!
See ticket 154527

For offline machines, use the time between last backup and last change of conn dot status to decide on backup status

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