Fix async v3 credential hydration for SSM resolution

[shaswot77]

Summary

• Fixes SLS_AWS_SDK_V3 - Unable to access SSM Parameters #132
• Deployment with SLS_AWS_SDK_V3=1 was failing ${ssm:...} resolution with UnrecognizedClientException because Serverless forced early resolution of AWS SDK v2 credentials and copied them into SDK v3. Since credentials sourced from environment variables were not valid at that point in execution, the resolved credentials were incorrect and then reused by SDK v3.
• We now await getPromise/refreshPromise (when present) in _resolveV2CredentialsForV3, so the v3 client config receives real accessKeyId,secretAccessKey and sessionToken. If no keys are available, we return undefined and allow SDK v3 to fall back to its own credential provider chain

[shaswot77]

@mnapoli Thankyou for running the checks! Could you please review the changes?

[mnapoli]

We will need to understand things better here. Let's decompose this:

Deployment with SLS_AWS_SDK_V3=1 was failing ${ssm:...} resolution with UnrecognizedClientException because Serverless forced early resolution of AWS SDK v2 credentials and copied them into SDK v3. Since credentials sourced from environment variables were not valid at that point in execution, the resolved credentials were incorrect and then reused by SDK v3.

Deployment with SLS_AWS_SDK_V3=1 was failing ${ssm:...} resolution with UnrecognizedClientException because Serverless forced early resolution of AWS SDK v2 credentials and copied them into SDK v3

So how is that responsible for the exception?

Since credentials sourced from environment variables were not valid at that point in execution

why are they not valid?

I'd love to understand the problem a bit more, because this is a critical refactoring and no tests were changed here.