Support offline mode for gh attestation verify

[steiza]

The main change is previously we always instantiated a TUF client for the public good and GitHub Sigstore instances. Now we only instantiate the TUF client we need, or no client if we are provided a custom trusted root.

Note that gh attestation verify still requires authentication, that is being addressed in #8995.

Some other changes are coming along for the ride:

• Set TUF cache validity to 1 day, to help serial verification
• Attempt to infer verification policy based on custom trusted root
• Make command output more friendly if you leave off required arguments

[cliAutomation]

Hi! Thanks for the pull request. Please ensure that this change is linked to an issue by mentioning an issue number in the description of the pull request. If this pull request would close the issue, please put the word 'Fixes' before the issue number somewhere in the pull request body. If this is a tiny change like fixing a typo, feel free to ignore this message.

[malancas]

Makes sense to me. Glad to see we can use the TUF cache and with picking the verifier on the fly.

[williammartin]

@steiza would you consider pulling in the commits in #9005 to this PR?

Commit 1

The first commit reworks the sigstore tests that you changed in this PR a little to be something I consider a little clearer. I appreciate there is some subjectivity here so I'll make my case. In configuring subtest setup in the outer scope, particularly when mutating shared resources (e.g. the SigstoreConfig) I think becomes challenging to keep the mental model and inhibits certain refactors. For example, if we move the current public good tests below the custom trusted root tests, we won't know that the code path has changed and a different verifier is being used. Similarly, if we mark the tests with t.Parallel() (which I'd love to do across the board) we run into the same issue because the outer scope is evaluated before the subtests are kicked off.

The change I've made ensures that each subtest is fully isolated, and I've leaned into helpers to remove noise from the tests. By using t.Helper and require we also reduce some error checking from within the tests themselves.

Commit 2

This is really just some additional testing that I added as I'm building my understanding of all the new pieces. It covers the first two branches in chooseVerifier:

I achieved this by adding two new attestation files that were copies of the "good one". In one I removed the entire verificationMaterial block and in the other I changed the x509CertificateChain to publicKey so that HasCertificate returns false.

Commit 3

This just seems like some unnecessary defensive coding. There is only one code path that leads here and it validates that the trustedRootFilePath is not empty. I got distracted trying to understand if this would ever be the case and in fact I think it would be extremely surprising behaviour to have no error and a nil *verify.SignedEntityVerifier. Very easy way to panic by accident.

[williammartin]

LGTM thanks!