More robust metadata syncing

[evgmik]

Below are quotes from communication with @sahib, quoted text belongs to @evgmik.

Here is the scenario, Ali and Bob made changes in their repos. They
were syncing from time to time. Let's even assume that they have fully
synced metadata.

Ali by incident nukes his ~/.brig/metadata.tgz.locked, but he could
synchronize with bob and he does. So on his side content is restored and
he is still tracking bob.
The problem is at bob's side, when he asks for diff or sync there will be
an error message

diff: No commit with index `3` found

Since Ali has only one diff (after first sync). If Ali does enough commits, there will be
proper patch number, but it will be with wrong  metadata which assumed
to be the same.  So sync is dangerous.

What I suggest is to put a hash to every diff message. If last know diff
is missing, we go back in history until we find the common ancestor,
worse case scenario if would empty repo state (which should have the
same hash in any repo for any user). This way we can recover from
destroyed metadata case with minimal loses.

I think you have a point here, although I'm not so much worried about
the scenario above. But the patch number is an additional concept we
might not need.  Also it's additional state that might get out of sync
or is calculated wrong because we introduced a bug.  We already have
hashes indicating "diffs" - those are just the commit hashes.

So it would be nicer if we could the patch API from this:

interface Sync {
    fetchPatch    @1 (fromIndex :Int64) -> (data :Data);
    fetchPatches  @5 (fromIndex :Int64) -> (data :Data);
}

to this:

interface Sync {
    # If "to" is empty, fetch complete diff until staging commit:
    fetchPatch    @1 (from :String, to :String) -> (data :Data);
    fetchPatches  @5 (from :String, to :String) -> (data :Data);
}

There is one downside of this approach (which is I think why I choose
patch numbers instead): The commit hashes on the metadata copy of the
remote will not be the same as on the remote - since the copy does not
have to be complete (some folders might be missing e.g.) - so we need to
store and trust the commit hashes coming from the remote. Using indices
was an easy way to workaround that storage.