Geo: Optimistic lock for registry tables to solve update-update races

More details in https://gitlab.com/gitlab-org/gitlab-ee/issues/5876

Per @nick's comment:

I think most of these problems can be solved if we throw optimistic locking into the *_registry tables, per http://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html

(I don't think we can use http://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html, because we can't reasonably hold open a row lock for an hour while git fetch runs).

In this model, we take note of the lock_version column before starting our long-running git fetch. If the lock_version has changed in the database (I think this will deal with rows being removed too), we discard the changes we were going to make to the database.

Ideas on why this wouldn't work for the general case, incl. specific examples, very welcome!

/cc @brodock @mkozono @ashmckenzie

@rnienaber @akaemmerle We may want to schedule it