Allow user to configure how SEV-SNP endorsements are fetched

[DomAyre]

Originally posted by @achamayou in https://github.com/microsoft/CCF/pull/4106#discussion_r947720759

TODO (gathered from comments below):

• [x] 1. Use in-enclave HTTPS client (#4226)
• [x] 2. Increase robustness of endorsement fetching (e.g. if request times out) (#4277)
• [x] 3. Add support for AMD endpoint (note: requires contacting 2 separate endpoints - see https://www.amd.com/system/files/TechDocs/57230.pdf) (#4277)
• [x] 4. Add node configuration entry to select between AMD and Azure endpoint (#4277)
• [ ] 5. Also fetch and verify CRL
• [ ] ~6. Cache endorsement certificates~. As discussed with @lynshi, Azure DCAP client caching is unlikely to be used in production with current SGX deployments so we will not prioritise this yet for SEV-SNP, until proven otherwise).
• [ ] 7. Allow for retrieval of endorsements certificates and CRLs via THIM agent, made available to ACI via environment variables.

[achamayou]

We want to default to the public AMD endpoint, because it will work anywhere, and allow the Azure endpoint to be configured where appropriate.

[achamayou]

We also need to look at https://github.com/microsoft/CCF/pull/4106#discussion_r947721064 when we revisit the endorsement endpoints.

[DomAyre]

We might need to swap out the client::RpcTlsClient with the enclave HTTP client so that it works with Monza

[DomAyre]

We also want to be robust to failures fetching the endorsements (specifically too many requests)

[achamayou]

@DomAyre the bulk of this issue is complete, can you close it and roll the remaining CRL/collateral fetching items into a freshly named 4.x ticket please?