Add different run modes for the TUF server, allow saving TUF keys as a secret

[bkabrda]

Summary

Addresses part of https://github.com/sigstore/scaffolding/issues/1182.

This commit implements features necessary to run/operate the TUF server in production much better:

• The TUF server can now be run in 4 different modes:
  • init - only init the TUF repository and exit
  • init-no-overwrite - same as init, but won't overwrite the TUF repository if it already exists
  • serve - only serve an existing TUF repository (no init)
  • init-and-serve - init and then serve (this is default to preserve backwards compatibility)
• The TUF repository can now be initialized/served from a given path, as opposed to always living in a /tmp directory.
• The TUF keys can optionally be exported as an individual k8s secret.

Some notes:

• The idea behind this PR is that:
  • There is a k8s Job/initContainer that runs the server with either init or init-no-overwrite to create the TUF repository at a mounted volume.
  • TUF server Deployment starts using only serve to serve the TUF repository from the mounted volume.
  • TUF keys are saved in the secret, so the admin of the system can download them and keep operating the TUF repository - they do so by updating TUF files localy and placing them in the volume.
• The PR could optionally be split into multiple PRs. I think this functionality is interconnected and hence makes sense to submit as a single PR, but let me know if you want me to split it into multiple ones.
• The choice to save the TUF keys into an individual secret (as opposed to adding them to the one that is already created) is kind of arbitrary. We could very well put everything in one secret, however I think having the option to delete the secret with keys (after it's downloaded by the admin of the system) and keeping the one with the repository is good to have.

Release Note

• The TUF server was modified to be run in 4 different modes:
  • init - only init the TUF repository and exit
  • init-no-overwrite - same as init, but won't overwrite the TUF repository if it already exists
  • serve - only serve an existing TUF repository (no init)
  • init-and-serve - init and then serve (this is default to preserve backwards compatibility)
• The TUF repository was made to be initialized/served from a given path, as opposed to always living in a /tmp directory.
• Option to export the TUF keys an individual k8s secret was added.

Documentation

It feels like this change would deserve some docs, but I don't know if there even are docs for the TUF server. I can certainly write something up if you can point me to the right place.

[bkabrda]

@evankanderson thanks a lot for your review! I think I addressed all the points. As noted in one of the inline comments, the currently saved secret intentionally explicitly excludes the keys directory from being saved. I'm not sure why it was coded this way, but I think it makes sense that these two are independent and the keys secret can be downloaded and deleted altogether. (I don't think this is a huge benefit, but it felt to me that it might be nice, YMMV of course).