Support for AMD SEV-SNP quotes in CCF

[jumaffre]

To provide support for AMD SEV-SNP in ACI, we should add support for retrieval and verification of SEV-SNP attestation reports so that an existing network can verify the measurement of a new joining node.

This includes:

• [ ] 1. Add test to make sure virtual node cannot join SGX/SEV-SNP service #4083
• [x] 2. Move quote retrieval/verification to new ccf::Pal abstraction layer #4083
• [x] 3. Retrieval of AMD SEV-SNP report on new node
• [x] 4. Retrieval of endorsement certificates (VECK, ASK, ARK), either from the Azure cache or AMD directly (via new configuration parameter)
• [x] 5. Parsing and verification of report on primary node (using AMD root of trust and certificate chain)
• [x] 6. Verification of collaterals against AMD root key
• [x] 7. Update existing code_ids table to cater for both SGX and SEV-SNP attestations.

Risk: ~It is not yet clear how to retrieve and verify the endorsement certificates for SEV-SNP attestation reports.~ This should be done via the dedicated Azure caching server or AMD server.

[jumaffre]

As discussed with @DomAyre, and with regards to point 7. above, it appears necessary to record the type of enclave measurement along with the actual measurement itself. Otherwise, it may be possible (depending on whether we support mixed network - see #4072), for members to allow code foo to run (assuming AMD SEV-SNP) but a completely different node from a different platform (e.g. SGX) with the same code foo to still be able to join the service. While it should be in practice impossible for a malicious user to craft a specific code measurement, separating the namespaces for code ids of different platforms would prevent a compromised platform (e.g. root attestation key of platform A has been leaked) to the confidentiality guarantees of an existing service on a different, non-compromised, platform B.

This will require changing the schema for the code_ids table, recording the type of platform along with the code status in the value. Because of backwards compatibility, a new 3.x node should still be able to read old values (the LTS compatibility test should catch this).