SHA-256 (only) not supported as a hash (root-signing-staging compat)

[jku]

Theoretically sigstore-java supports both/either sha256 and sha512 as TUF artifact/targetfile hash.

Unfortunately the download url is wrong if repository does not use sha512: versionedTargetName = targetData.getHashes().getSha512() + "." + targetName; this should use one of the hashes actually used by the repository.

This came up in root-signing-staging:

• tuf-on-ci currently uses sha256 only
• this had not had an effect on the root-signing-staging metadata before because artifact changes had not been made before now (this surprised us -- we had already deployed the code change when tuf-on-ci migration happened but clients had not seen the metadata change before we tried to merge an artifact change today)
• There is currently a root-signing-staging deployment waiting on a decision on this https://github.com/sigstore/root-signing-staging/issues/161 (see https://github.com/sigstore/root-signing-staging/issues/161#issuecomment-2304084483 for summary)

Slight complication is that production root-signing is about to migrate to tuf-on-ci and the original plan was to make some artifact changes right away... Current plan is:

• let the staging deployment continue (breaking sigstore-java on staging)
• Avoid making artifact changes in the root-signing migration so this doesn't come up in production in near future
• Fix the bug here in sigstore-java
• then evaluate again what we do with hashes in root-signing production

[jku]

There is currently a root-signing-staging deployment waiting on a decision on this

We deployed this change to staging after a discussion with @loosebazooka:

• this breaks sigstore-java (on staging only)
• client fix should be easy
• plan is to avoid these changes in root-signing production signing event that is likely happening next week to avoid breaking java clients in prod (even if there is a sigstore-java fix by that time)
• We may still do these changes at a later date in root-signing production