AWS: set retry policy on glue client

[edgao]

similar to ff81344#diff-6c7387be14971c2febd327b91d20ef0e12fc705fc3e7a8449387d8496d418190, except on the glue() method. We're seeing some rate-limit errors when operating against Glue, and the default retry policy (LEGACY, i.e. 3 retries + no backoff) probably isn't helping.

I didn't add a new unit test - that PR adds a test to verify that applyRetryConfigurations works correctly, but that's orthogonal to whether or not the method is actually called. TestAwsClientFactories returns the client object directly, and I couldn't figure out how to easily extract the retry policy from a GlueClient object.

I could be convinced to add this invocation on the dynamo() method as well - LMK

[singhpk234]

This looks reasonable to me, i think dynamo is used both for cases like lockmanager as well as as a catalog so should be fine if we wanna use it

@edgao worst case you can use reflection ? i wonder if we can just test in the way we tested prev ones

[edgao]

This never was tested, though it probably should be. I'll defer to you on reflection - personally I don't love it (e.g. AWS changes the field name, now our test is broken). But I'll implement it tomorrow and we can see how it looks.

Will add the retry policy on the dynamo client as well 👍

[edgao]

@singhpk234 how does this look?

Looking through AwsClientFactories, I think we could probably also refactor it to accept a mocked AwsClientProperties object + assert that we at least called awsClientProperties.applyRetryConfigurations. But that would have been more code churn, and it still doesn't really verify that the client object was constructed correctly

[edgao]

actually derp, I think I just found the right sequence of method calls to do this without reflection 🤦 one minute

[singhpk234]

LGTM, thanks @edgao !