setup metadata publishing

[jku]

once #4 is handled we should start publishing metadata, even if it's manually built (as having metadata enables client development and makes it easier to reason about workflows): the real pipeline will likely involve a separate cloud service but MVP could be just GitHub Pages (like I've done with https://jku.github.io/tuf-demo/). I think we want the metadata working storage to be git for easy debugging -- we can start by storing it in this repository but in reality possibly want it in a separate one.

[joshuagl]

sigstore/root-signing uses Git as storage but replicates that to a cloud bucket – something similar probably makes sense here? As you've suggested, git gives us that highly desirable observability. Whereas replicating it to a cloud storage that the client interacts with better reflects standard content repositories.

[jku]

My current thinking on the publishing pipeline is:

• maintainer tools run on maintainer machines, connect to playground service running on cloud (this is future work, nothing exists yet)
• playground cloud service has both HTTP accessible components (like target upload) and others (like timestamp). This playground service should preferably be installable on local machine as well.
• The playground service uses git as data storage for metadata, and has credentials to push changes to the remote git repository -- git is used for easy observability
• There is a separate publishing mechanism from git repository to the HTTP endpoint that clients use. This could be triggered by playground service but I don't yet see why it would need to -- I think we can always publish when changes happen. GitHub Pages seems like a reasonable choice for this if the git repository is on GitHub.
• In addition, the playground service needs to be able to publish the target files (artifacts) somewhere. Currently they all go into git but that has obvious drawbacks.

A drawback of a setup like this is that it's not super easy to replicate as you need all of these:

• playground cloud service
• metadata storage service (git repo)
• metadata publishing service
• targets publishing service

That said, replicating containerized "testing install" would not be horribly difficult:

• run playground service in one container
• run a git server, and simple publishing web server in another container

(this is not something I plan to implement now and would be comparable to the Warehouse local install, not a way to deploy to production)