CDH | Support passport mode KBS

[jialez0]

This PR is rely on #465 .

[Xynnn007]

Hi @jialez0 it seems that this PR aims to

1. A plugin in kms crate, s.t. kbs supports to get token from AA with token type coco_as
2. Use the token provisioned by CoCoAS to access KBS resources

Before this PR, we have the following calling stack

1. A plugin in kms crate, s.t. kbs-resource will get token from AA with token type kbs
2. Use the token provisioned by KBS to access KBS resources

So the difference is step 1.

Current code to handle step 1 is

1. The KbsClient builder will use AATokenProvider to get tokens when access the resources. This means it is not a background check model. The concrete calling frames are
   a. When getting resource from KBS, it will first get a token if not any. https://github.com/confidential-containers/guest-components/blob/main/attestation-agent/kbs_protocol/src/client/token_client.rs#L40-L42
   b. update_token() will call the underlying AATokenProvider's get_token()
   c. get_token() handler will actually connect AA and call AA's get_token() API with token type kbs.

So to my understanding, if we want to implement this, we just need to change the defination of TOKEN_TYPE in the runtime. For example, it would default be kbs, and we can configure it to coco_as or other types when launching the CDH.

To achieve this, I recommand that we can set the token_type here from an env. If the env is not set, by default will be set to kbs. Env helps us do not need to pass this parameter from the top layer of CDH through a bunch of function calls. The top level logic of CDH will set this env after reading from the config.

The advantage is we can avoid using a compilation-time-determined version of CDH to leverage CoCoAS token or KBS token, instead runtime. This helps us to decrease complexity of rootfs-es.

How do you like? I might have ignoreg some important details.