Requiring collateral to be in cache on verification causes problems

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