backup: dont remove old increments because then we lose the backup history right before the last full backup, instead let them disappear along with full backups when a whole chain becomes very old

Doesn't seem like 2 minutes is a problem, but 4 minutes seems better. A little less bandwidth, possibly less battery usage (though we don't have evidence that's actually true), and the interval should be shorter than any peer timeouts that might occur due to inactivity

fixes #129

if the machine didn't have resolvconf before (my box didn't after an upgrade from Ubuntu 13.xx), make sure it has it now and archive any old resolv.conf since it should now only list 127.0.0.1 for bind9

migrate the migration state from MIGRATIONID in /etc/mailinabox.conf to STORAGE_ROOT/mailinabox.version so that the data format of STORAGE_ROOT is stored in the directory itself

after creating the local encrypted backup, execute the after-backup script if the user has provided one to copy the files to a remote location

whats_next: offer DNSSEC DS parameters rather than the full record and in validation allow for other digests than the one we suggest using

fixes #120 (hopefully), in which Gandi generates a SHA1 digest but we were only checking against a SHA256 digest

Also see http://discourse.mailinabox.email/t/how-to-set-ds-record-for-gandi-net/24/1 in which a user asks about the DS parameters that Gandi asks for.

dont ask the user for the machine's IP address if we can be sure our guess is right (trust icanhazip to give us the right answer)

put a 15-second timeout in asking icanhazip.com for our IP address, although this limit does not seem to actually work (i.e. if I set the limit to 5 seconds, curl still hangs 10+ when I turn off my network connection)