Replace the internal STS client with the official one

[6XGate]

The internal STS client is missing most of the functionality of the official Amazon SDK's STS client. The official client, or an update to the internal one, will be needed to use EC2 Instance Profile roles and local SSO credentials with this library.

[norberttech]

Hey, let me just bring some context about the decision of not using anything from amazon "official" sdks.

I didn't wan't to use it because it's just poorly designed. Just look how many dependencies they are pushing on you:

php: >=7.2.5
ext-json: *
ext-pcre: *
ext-simplexml: *
aws/aws-crt-php: ^1.2.3
guzzlehttp/guzzle: ^6.5.8 || ^7.4.5
guzzlehttp/promises: ^1.4.0 || ^2.0
guzzlehttp/psr7: ^1.9.1 || ^2.4.5
mtdowling/jmespath.php: ^2.6
psr/http-message: ^1.0 || ^2.0

what's exactly the reason to force anyone to use guzzle? What if my system is not using guzzle, then I need to have two completely different http clients because some devs decided so? or the mtdowling/jmespath.php (whatever it is)

Another problem is that this library is massssive, which is another design flaw.

My recommendation here would be to create an abstraction layer and maybe a bridge (for those folks that have nothing against using amazon sdk) but without forcing everyone else to become dependant from all those packages. Obviously upgrade the the internal client would be the best possible solution.

[6XGate]

Easy to do.

[jasonhebert]

We found an internal solution to this issue requiring no change to this library. :)