* We now check for in-progress backups when asked to perform one, and don't
bother firing off another one concurrently (nor do we adjust the scheduling;
after all, someone asked to do a backup "now" and we're doing one, so we are
in line with expectations). We also defer backup passes while a restore is
in flight, and abort attempts to perform a restore during a backup pass.
* When a backup attempt fails, we now ask the transport how far in the future we
should put our retry. Previously we were simply not bothering to consult with
the transport, so we would wind up retrying backup while network connectivity
was known to be down, etc.
Change-Id: Ic7758010b74e06e90c50d46b7b0dd01b17af7c90
21ab6a5bdb