Version clustered, observed repositories in a reasonable way (by largest discovered HEAD)

Summary:
Ref T4292. For hosted, clustered repositories we have a good way to increment the internal version of the repository: every time a user pushes something, we increment the version by 1.

We don't have a great way to do this for observed/remote repositories because when we git fetch we might get nothing, or we might get some changes, and we can't easily tell what changes we got.

For example, if we see that another node is at "version 97", and we do a fetch and see some changes, we don't know if we're in sync with them (i.e., also at "version 97") or ahead of them (at "version 98").

This implements a simple way to version an observed repository:

• Take the head of every branch/tag.
• Look them up.
• Pick the biggest internal ID number.

This will work except when branches are deleted, which could cause the version to go backward if the "biggest commit" is the one that was deleted. This should be OK, since it's rare and the effects are minor and the repository will "self-heal" on the next actual push.

Test Plan:

• Created an observed repository.
• Ran bin/repository update and observed a sensible version number appear in the version table.
• Pushed to the remote, did another update, saw a sensible update.
• Did an update with no push, saw no effect on version number.
• Toggled repository to hosted, saw the version reset.
• Simulated read traffic to out-of-sync node, saw it do a remote fetch.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4292

Differential Revision: https://secure.phabricator.com/D15986