resume interrupted backups

[fd0]

This breaks out some commits from #252 (which was clearly too large to be done in one PR). The code in this PR adds resuming of interrupted backups by regularly writing an index (utilizing the new supersedes field) and reading these when a backup should be resumed.

Closes #59

[fd0]

@episource I've handled the bug you discovered, thanks again.

[episource]

Is a RWMutex reantrant? The documentation does not say anything about this...

~~Context: ~~
AddInFlight acquires a RW-Lock (mi.inFlight.Lock()) and then calls Has, which tries to acquire a Read-Lock (mi.idxMutex.RLock()). Without RWMutex being reantrant this should fail/dead-lock.

Assuming go locks to be reantrant I tried the same while implementing my draft of StoreInProgress. Due to that I learned the hard way, that my assumption was wrong and Mutex (not RWMutex) is not reantrant.

Edit: Reading my comment again, I noticed that two different lock objects are involved.

Edit: Nothing is locked twice. Everything is alright.

[fd0]

Uhoh. I'll have a look, thanks again!

[episource]

No, just forget my comment. It's plain wrong.

[fd0]

Hm, I'd expect that acquiring the r lock while an r/w lock is already held leads to a deadlock...

[fd0]

Ah, indeed, now I see it.

[fd0]

Any other comments? Otherwise I'll merge this branch now :)

[episource]

Not from my side...

[fd0]

cool