Minimal changes version of new summary format for flatpak

[Alexander Larsson <alexl redhat com>]

I've been doing some research on the summary dicussions from
yesterdays meeting, and it looks like the minimal changes we need for
flatpak to do its own summary format is pretty small, while being very
flexible.

First of all, flatpak already always resolves refs to commit ids
before calling ostree to pull, so the summary file is only needed
by ostree for these things:
 * Finding deltas
 * List all refs if we are mirroring
 * Quick access to "mode" and "tombstone-commits" options, otherwise
   it has to download the config file separately.
 * In the p2p code (ostree_repo_find_remotes_async) we use the
   commit timestamp extracted to the summary metadata to find the
   peer with then most recent version.
   This is not used by flatpak (anymore).

So, my proposal is that:

 * We merge support for deltas outside the summary. Unless you 
   specially configure it ostree still adds deltas to the summary for 
   backwards compat.
 * Set a key in the config file when updating the summary saying that
   deltas are available outside the summary.
 * Add a client-cached version of the remote config file, using etags 
   to only update it if it changed. Ensure we have the latest version 
   each time we start a pull operation.
 * If in a pull operation, if we have commit ids for all refs, we're 
   not mirroring and the (cached) config file says deltas are available
   on the side, then don't download the summary (as we don't need it).
   (Code-wise this is the current codepath as if the summary is 
   missing on the server).
 * Add an API that lets you sign data similar to signatures are signed 
   so that flatpak can sign its own summary files. This is essentially 
   the reverse to ostree_repo_gpg_verify_data().

In a setup like this flatpak (or other clients) can do whatever it
wants with the summary files both on the client and the server. If the
repo is an old version then both flatpak and ostree will download,
cache, share and use the summary with deltas like before. We would
need this summary file anyway for older clients. However flathub could
limit the set of deltas in the fallback summary to save space
(i.e. only have x86-64 deltas there).

However, if the remote is "new" it can have subset summaries, and the
client can update them whatever way it wants (i.e. w/ deltas), and as
long as it resolves refs itself ostree will never download the old
summaries. In practice for flatpak it will probably be very similar to
the indexed summaries the ostree branch had, but in theory it wouldn't
even have to use summaries files at all, but instead a dynamic
query-based REST api.

The old summary is still there as a fallback, but also as a
standardized way to do direct operations on the repo, like using the
ostree cli. In this setup also non-flatpak ostree users doesn't get
summary file format change pushed on them (other than the deltas).

I like this setup, its will allow me (and other clients) a great
deal of flexibility, while still having a single standardized format
for the ostree cli operations.