feat(cdh): add aliyun KMS attestation client to fetch resources by remote attestation

[jialez0]

What this PR does

Adds a new attestation client type to the aliyun KMS plugin in
confidential-data-hub. It lets a confidential guest fetch confidential
resources (KMS secrets) from an Aliyun KMS instance that has the Trustee
Attestation Service integrated, authorized by TEE remote attestation
instead of a pre-provisioned client key or any long-term credential.

Background

Besides serving secrets over the RCAR protocol from a standalone Trustee KBS,
the Trustee Attestation Service can now be integrated inside an Aliyun KMS
instance. In that model the KMS itself verifies the TEE evidence and returns
the secret encrypted to a public key that is bound into the evidence, so the
plaintext is only recoverable inside the attested TEE. This client implements
the guest side of that flow.

How it works

All requests are RPC-style POST / form bodies signed with the Aliyun POP
HMAC-SHA1 scheme, sent to the dedicated instance endpoint
({instance}.cryptoservice.kms.aliyuncs.com) over its private CA.

1. Fetch a temporary STS credential from the ECS RAM role via IMDS — no
   long-term secret is stored in the TEE.
2. GetChallenge → { Nonce, ChallengeToken }.
3. Generate an ephemeral RSA-2048 key pair, build the structured runtime
   data { challenge_token, nonce, tee-pubkey }, hash it canonically with
   SHA-384 (via canon-json, matching the AS), and let the attestation-agent
   embed the hash into the TEE evidence report data.
4. GetSecretValue with a Trustee Recipient carrying the evidence; the KMS
   verifies it and returns CiphertextForRecipient = RSAES-OAEP-SHA256(secret).
5. Decrypt CiphertextForRecipient with the ephemeral private key.

Integration

The client plugs into the existing vault sealed-secret Getter path, so no
routing change is needed. A Vault secret whose provider is aliyun and whose
provider settings carry client_type: "attestation" is served by this client:

{
  "client_type": "attestation",
  "kms_instance_id": "kst-xxxxxxxx",
  "region_id": "cn-hangzhou",
  "ecs_ram_role_name": "your-ecs-ram-role"
}

The KMS instance private CA is read from
{ALIYUN_IN_GUEST_KEY_PATH}/PrivateKmsCA_{instance}.pem, mirroring the
existing client_key layout.

Testing

• Unit tests: canonical-JSON hash is order independent, RSAES-OAEP-SHA256
  round-trip with the ephemeral key, exported public exponent is AQAB.
• End-to-end on a real Intel TDX ECS instance against a KMS instance with the
  integrated attestation service: sealing a Vault secret and unsealing it
  returns the provisioned plaintext.

Note on the OAEP backend

The ephemeral key uses the rsa crate directly to guarantee OAEP with SHA-256
for both the digest and MGF1. The shared crypto crate's OpenSSL backend still
maps PaddingMode::OAEP to OpenSSL's default (SHA-1) OAEP, which would not
interoperate with the KMS RSAES_OAEP_SHA_256 wrapping.

[shankailun-aliyun]

@jialez0 ，您好，您的请求已接收，请耐心等待结果。

[shankailun-aliyun]

@jialez0 ，您好，未检测到有镜像需要构建，如需重新检测请评论 /start 。

[shankailun-aliyun]

@jialez0 ，您好，您的请求已接收，请耐心等待结果。

[shankailun-aliyun]

@jialez0 ，您好，未检测到有镜像需要构建，如需重新检测请评论 /start 。

[Xynnn007]

RSA算法是KMS那边要求的么？ 可否考虑椭圆曲线系列的