Also query ECS container creds endpoint for KMS when no storepass is set

[AlexTMjugador]

Issue #147 and its linked PR made it much more ergonomic to use jsign within an AWS EC2 instance, but as highlighted in the latter comments on that issue, it's not helpful when running jsign in the context of AWS Elastic Container Service (ECS) based products, such as AWS Fargate, AWS EKS, AWS Codebuild, and AWS Greengrass. The precise technical reason for this is that ECS environments don't have that EC2 IMDSv2 endpoint exposed to them, so they can't use it.

As the official AWS SDK documentation states, the official SDK handles this situation by fetching credentials from a specific ECS container credentials endpoint, which doesn't share any host or path with IMDSv2, on the ContainerCredentialsProvider class.

Roughly, the official container credentials provider works as follows:

• If the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable is set, it concatenates it with a well-known base URI, http://169.254.170.2, configurable through the AWS_CONTAINER_SERVICE_ENDPOINT parameter. (In production deployments, such URI can be considered a constant; changing it is mainly useful for testing purposes.) Then, it sends a HTTP GET request to the resulting endpoint, which is expected to return a JSON object in its body with the AWS credentials for the container. Optionally, an Authorization header in the request may be set to the value of either the AWS_CONTAINER_AUTHORIZATION_TOKEN or AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE environment variables, if any of those are set.
• Else, if the AWS_CONTAINER_CREDENTIALS_FULL_URI environment variable is set, the same request as above is sent to the endpoint determined by this variable, without any modification. The contents and handling of the response to this request are the same as above.

Experimentally, I've found AWS Fargate to only set AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, without any authorization token. But the AWS documentation suggests that AWS EKS may make use of the full URI and token environment variables, so it's fair to say that supporting them is also useful in practice.

To improve on the situation, these changes implement a lightweight but feature-complete ECS container credentials client in jsign. This credentials client attempts to fetch credentials before its counterpart for IMDSv2, which guarantees that both EC2 and ECS environments are handled appropriately without any manual configuration, following the same logic as the AWS SDK. If neither credentials provider worked, the user is instructed to manually pass AWS credentials as before, and the resulting exception stack trace contains details on why both providers failed.

I've tested this custom client logic to work successfully on a real AWS Fargate deployment. The documentation was also updated to reflect this new provider, and unit tests for it added.

[ebourg]

Merged, thank you for the PR!