[ci/tuf-repo] multi-SP repos + use released SP images + add gimlet-e

[iliana]

• First half of Build a TUF repository with SP images for all relevant hardware revisions #3893, which adds all the SP images to our repos. We'll need to test this on dogfood. We still have two separate repos for now for the different ROT images; opened wicket / the control plane cannot know which signature the ROT wants #3954 to track.
• We are now using released SP images from the release assets over at https://github.com/oxidecomputer/hubris/releases. See also RFD 412. Unfortunately the current release assets do not yet update the VERS field of the caboose so those still display as 0.0.0-git, which is reflected in the manifest.
• Adds gimlet-e support.
• Stops splitting the repo into 1 GiB parts since oxidecomputer/buildomat@d22ebd7 is deployed.

This again changes the repo URL, so I will need to remember to update the script in meta after this lands.

[jgallagher]

LGTM. Naming things is hard - all seems fine to me. Once we can drop the pvt1 repo we'll only have one, at which point the suffix maybe isn't super relevant anymore? Could move to repo.zip, or oxide.zip, or oxide-repo.zip, ...

[jgallagher]

Should we go ahead and add gimlet-e too? It's available in dvt-dock. (We do not yet have new psc/sidecar hardware revisions.)

[iliana]

Might as well. I'll update that in a bit. (In the very near-term we're going to switch from using dvt-dock to tagged-and-released Hubris artifacts, hopefully tomorrow, and I was planning on adding it then.)

[iliana]

Upon further glancing at the generated manifest, this is listing duplicate ROT images way too many times. I'll rework the script tomorrow, although I may wait until I know how to pull newly-tagged SP images.

[iliana]

Latest commit is a re-do and does a handful of other things too. The pull request description is updated with details.

[jgallagher]

oxidecomputer/buildomat#36 makes it somewhat annoying to test the repos from this PR, but we really need this to land. Do you think we should:

• Merge as-is; the buildomat issue is inconsistent so doesn't totally preclude using the resulting repos
• Revert the removal of splitting the zip up into < 1 GiB pieces and then merge?

I have a very slight preference for the latter but am fine with either.

[iliana]

I'm honestly surprised that just slightly above >1 GiB seems to be the point where failures seem to occur in oxidecomputer/buildomat#36. So I am also slightly in favor of dropping the combined repo for now. I will get that pushed and then merge on success.

[iliana]

I also now have the opportunity to remove the PVT1 repo, since that rack has been updated enough to understand multiple SP image revisions. That is done.

Will merge once everything passes, and notify the dogfood channel (and update the script in the instructions) for the updated repo series naming ("dogfood" -> "rot-staging-dev").