Trusted resources works only for storage version of the API

[lbernick]

Expected Behavior

We can swap the storage version of Pipeline APIs at any time without impacting users.

Actual Behavior

Trusted resources verification happens after a remote Task or remote Pipeline is converted into the storage version of the API. Task conversion happens here and verification happens here.

This means that if someone creates a verified v1beta1 Task and stores it in a git repo, when we swap the storage version of the API, this task can no longer be verified, since it will be converted to v1 before verification.

I understand trusted resources has few (no?) users right now and is in alpha, so this breakage might not be a huge deal; however, this is a problem for 2 reasons:

1. we will make more storage version swaps in the future; i.e. we will probably have a v2 api eventually
2. this is blocking resolution of Versioned validation of referenced Pipelines/Tasks #6616, which is in turn blocking moving to v1

Additional Info

It may still be doable to bubble up resources verification results to the taskrun/pipelinerun status, as proposed here, but I suspect it will get messy especially with the addition of "warn" mode. As evidence, #6502 is a refactoring PR that moves trusted resources verification even farther from where the remote task is fetched, in order to make it easier to set the taskrun status.

(sorry in advance for potentially backseat driving a proposal I haven't been super involved with) I'm wondering if we should treat trusted resources verification more how we treat task validation: either it passes and you have a valid task, or it doesn't and you have an invalid task. This might also help with not being able to verify local tasks because we call setdefaults as soon as a task/pipeline is applied to the cluster.

FYI @bobcatfish @wlynch