Requiring collateral to be in cache on verification causes problems

Start by tracing the verifier function and how it currently requires collateral to be cached. Compare the synchronous-fetch and attester-side-fetch approaches described in the issue, including their effects on retries, payloads, and planned network-backed verification checks. Done means verification no longer requires a pre-warmed collateral cache and the chosen approach is covered by tests.

I've been trying to use this library to replace cvm-reverse-proxy for Flashbox. And needing to have the collateral already in cache for verification to pass is quite annoying. In the end i decided its safest to use the older EKM-based protocol for Flashbox.

The proxy client is generally targeting a single host (the proxy server) so it doesn't make sense to do a full PCCS 'pre-warm' and fetch all available collateral when we will only need one of them. So we rather have to do a failed connection (missing collateral), and then keep waiting and retrying. With a one second delay between retries, i currently need to wait till the third attempt to get a successful connection.

This feels cumbersome, inefficient and error prone, and like there must be a better way.

Worse still, we have planned additions to verification which will also require network fetch:

• Proof of cloud (fetch to GCP bucket to check if PPID present): https://github.com/flashbots/attested-tls/pull/54
• Checking for GCP signed firmware associated with an MRTD: https://github.com/flashbots/attested-tls/pull/47

Related issue: https://github.com/flashbots/attested-tls/issues/2

Possible solutions i am considering:

1. Just doing a synchronous fetch during the verifier function. This is not ideal, but its made slightly better with dcap-qvl's new ColleratalClient api which allows us to pass in a custom HTTP client (eg: ureq) and still use dcap-qvl collateral fetch code. Implemented in https://github.com/flashbots/attested-tls/pull/63
2. Do collateral fetching on the attester side. That is, when generating an attestation, we also fetch collateral and include it in the payload. Good because we do just one fetch regardless of how verifications, even if the verifications are by different peers. Bad, because this is an API breaking change, increases payload size/complexity, diverges from standards, and is quite opinionated / use-case-specific. https://github.com/flashbots/attested-tls/pull/65

Personally i am leaning towards option 1.

cc: @0x416e746f6e