Partial design doc:

https://docs.google.com/document/d/1xDIwTby2PxPLyEJMwCxv7n3gcRjgMAoRf5tOHlcDkqA/edit#

The basic premise here is that we currently organize almost all of our data by Build/Test/Whatever and then (poorly) by Commit, but:
  * commits have an order which is difficult to query, including going 'up' towards a ref. This means queries like "next build" are extremely difficult to implement.
  * Every form of additional data we need to associate with a commit requires a new service and/or new datastore models. Each service has to re-invent solutions to these problems.

Instead, we could potentially have a service to index commits (bi-directionally, including correct git parentage information), and then allow other authenticated services to associate data with the commits (i.e. builds, test results, etc.).

Implementations to consider:
  * An appengine app
  * A GKE app (maybe with spanner datastore)
  * A hybrid of those two (like logdog)
  * Git notes (potentially too low bandwidth and complex addition procedure, doesn't solve history forward/back indexing)