Support (require?) storing builds in a git repository

[cgwalters]

I've been thinking about #184
Right now the data model is pretty simple. If we add tagging it gets more complex.

One thing I've been thinking about, and this is inspired by previous discussions around rpm-md - what if we took a page from Rust's cargo and stored our builds.json as well as the meta.json in git?

Then our tags would literally just be git tag.

Another approach is to store builds in ostree: #189 (comment)

(However today ostree doesn't have tags as such)

The main reason I want to do this is to retain some history of builds even after we do some pruning in production.

[cgwalters]

At a high level...there have definitely been some times when I wondered about using git for ostree from the start too; some of the same ideas behind bup. It's really not worth changing now though.

[ashcrow]

We are producing meta.json and builds.json now via our pipeline ... though these are not being stored in our git repository.

[lucab]

The following points, coming from a discussion with @jlebon, are partially related to the discussion in this ticket.

• builds in the JSON manifest are currently sorted newest-to-latest, with new builds pushed at index 0 and displacing existing one. As a consumer, I would prefer an append-only list with stable indexes.
• pruning does not fit well with cincinnati update model. An evetually-pruned release can't be discovered and inserted in the update graph. Thus, a host on a pruned release will (eventually) end-up in a EOL state where it can't auto-update anymore.

[dustymabe]

there are different options for pruning

• For any prod ref I don't think we'd prune aggressively at all
• We can prune content without pruning commit info (i.e. just keep the metadata but drop the content), which should allow Cincinnati enough info to operate.

[cgwalters]

Dup of #159