Bundle DCAP collateral together with attestation to avoid fetching on the verifier side

[ameba23]

This is a possible solution to #58

In order to avoid needing to do a network fetch to retrieve DCAP collateral during verification, in this PR the attester fetches collateral at the point of DCAP attestation generation, and includes it in the evidence payload.

Since collateral is signed by Intel it does not matter from a trust perspective whether it is provided by the (untrusted) attester or retrieved by the verifier.

The advantage is we do just one PCCS fetch per attestation regardless of how many times it is verified, even if the verifications are by different remote peers.

The disadvantages:

• This is a protocol breaking change. Could be made not protocol breaking by making it optional to include collateral.
• Increases payload size/complexity
• Diverges from standards
• Is quite opinionated / use-case-specific. This specifically caters to a nuance in our attested-tls protocol, making the attestation crate less useful as a general purpose library.

For these reasons i am not suggesting we merge this, but i wanted to provide a complete possible solution.

Edit: Looking into this more as @Ruteri thinks this is maybe worthwhile. Since we since merged the PR integrating with attest, this is going to look quite different as we have both platform metadata and collateral in the attestation evidence payload.

An additional concern for including evidence in x509 certificate extension: Rustls caps Certificate handshake messages at 64kb. Thats probably ok for the evidence/collateral sizes we see right now, but this could very well be a problem in the future. For this reason, this PR also switches the attestation payload encoding from JSON to scale to significantly decrease payload size. Backwards compatibility for JSON encoded payloads is provided. See #75

TODO:

• This treats collateral as an optional field in the evidence payload, meaning the verifier still has to do a PCCS fetch when handling the case that it is not there. Could make it mandatory.
• Does not yet include collateral in the Azure payload.

[samlaf]

Hey @ameba23, working on some other change I need in here and found this. Don't understand this PR very well but it seems to have cross-concerns with my upcoming PR, so leaving a msg from Claude here for you:

Quick context and a status question. (Claude authored)

We use attestation as a relying party for a one-time event rather than a live handshake:
at network founding we verify each node's TDX + vTPM quote and archive the evidence as
permanent provenance. That archive stops being re-verifiable once the collateral's
nextUpdate passes, so we need two things this crate almost has already — verification at
an explicit now (the collection instant, which everything below the public API already
threads), and the verifier reporting which collateral bundle it used. I'll open that as its
own PR since it's orthogonal to both #63 and #65: no wire change, nothing added to the
payload, so it's also neutral wrt the 64 kb cap in #75.

Where this one matters to us: if collateral ends up in the evidence payload, our archive
keeps it verbatim for free and we'd drop a separate archived file. We'd still need the
explicit now, since bundling collateral doesn't stop it expiring.

So — you wrote you're not suggesting this be merged, and on #58 you lean toward option 1
(#63). Is that still your position, or did @Ruteri's interest move it? It decides whether
we plan around payload-bundled collateral or not.