expire revisions on remote servers

[dhnasa]

depends on #62

closes #30, PL-131863

• Change is documented in changelog

• Support backup job migration across servers

• Add tags {set, add, remove} subcommand

• Add expire subcommand

• logging: improve exception formatting

• logging: add taskid

• Add push and pull subcommand

• Add server: selector to revision spec

• Coordinate backups for the same job between servers
  The server with the largest number of local revisions is the leader.
  If the leader is offline another server will take over.

  This assumes that all servers share the same rng and thus
  schedule the backup at the same time. If this is not the case more
  backups than necessary may be created (but not less).

Security implications

• Security requirements defined? (WHERE)
  • Minimise attack surface area: api access requires api key
  • Establish secure defaults: missing api key(s) prevent api access
  • Fail securely: invalid data does not crash the daemon (but may crash the backup process indefinitely)
  • Fail securely: network failure/unresponsive remote does not prevent backup (existing data remains valid until the remote server is removed from the config file)
  • Principle of Least privilege: only "dead" backups can be changed by remote servers
  • Don't trust services: malicious backy server can prevent new backups on other servers (but this is by design?, maybe add some plausibility checks e.g. no backups in the future? or timeouts when waiting for the leader to finish)
• Security requirements tested? (EVIDENCE)
  • unit tests