The LogRetention Custom Resource used to be able to handle server-side throttling, when a lot of requests to the CloudWatch Logs service are made at the same time.
Handling of this error case got lost during the migration to SDK v3.

If we have (read: a lot) LogRetention Custom Resources in a single Stack, CloudFormation apparently applies some internal breaks to the amount of parallelism. For example it appears that resources are batched in smaller groups that need to be completed before the next group is provisioned. And within the groups there appears to be a ever so slight delay between individual resources. Together this is enough to avoid rate limiting in most circumstances.

Therefore, in practice this issues only occurs when multiple stacks are deployed in parallel.

To test this scenario, I have added support for integ-runner to deploy all stacks of a test case concurrently.
Support for arbitrary command args already existed, but needed to explicitly include the concurrency option.

I then create an integration test that deploys 3 stacks à 25 LogRetention resources.
This triggers the error cases described in #26837.

The fix itself is twofold:

• Pass the maxRetries prop value to the SDK client to increase the number of attempts of the SDK internal throttling handling. But also enforce a minimum for these retries since they might catch additional retryable failures that our custom outer loop does not account for.
• Explicitly catch ThrottlingException errors in the outer retry loop.

Closes #26837

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license