fix: configure Faraday::Retry to handle DataDog API rate limits

[maratkomarov]

When the DataDog API exceeds its limits, the tool crashes with the following error:

bundler: failed to load command: datadog_backup (/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/bin/datadog_backup)
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:1268:in `raise': 507 errors (Concurrent::MultipleErrors)
the server responded with status 429 (Faraday::TooManyRequestsError)
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/response/raise_error.rb:34:in `on_complete'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/middleware.rb:18:in `block in call'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/response.rb:42:in `on_complete'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/middleware.rb:17:in `call'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/middleware.rb:17:in `call'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/response/logger.rb:23:in `call'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-retry-2.2.1/lib/faraday/retry/middleware.rb:153:in `call'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/middleware.rb:17:in `call'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/rack_builder.rb:152:in `build_response'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/connection.rb:444:in `run_request'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/faraday-2.9.0/lib/faraday/connection.rb:200:in `get'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/bundler/gems/datadog_backup-1229c0c8908f/lib/datadog_backup/resources.rb:50:in `get'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/bundler/gems/datadog_backup-1229c0c8908f/lib/datadog_backup/dashboards.rb:27:in `get_by_id'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/bundler/gems/datadog_backup-1229c0c8908f/lib/datadog_backup/resources.rb:67:in `get_and_write_file'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/bundler/gems/datadog_backup-1229c0c8908f/lib/datadog_backup/dashboards.rb:15:in `block (2 levels) in backup'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:1593:in `evaluate_to'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:1776:in `block in on_resolvable'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:359:in `run_task'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:350:in `block (3 levels) in create_worker'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:341:in `loop'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:341:in `block (2 levels) in create_worker'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:340:in `catch'
/opt/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:340:in `block in create_worker'
the server responded with status 429 (Faraday::TooManyRequestsError)

This PR configures the Faraday::Retry middleware to:

1. Specifically handle Faraday::TooManyRequestsError, which is not covered by the default error handling settings in the middleware.
2. Use the x-ratelimit-reset header instead of the default ratelimit-reset to actually manage retry timing after hitting rate limits.

[kamranf]

@maratkomarov thanks a lot for the submitted fix. It looks good to me.

[github-actions]

🎉 This PR is included in version 4.0.0 🎉

The release is available on:

• v4.0.0
• GitHub release

Your semantic-release bot 📦🚀