Expose x-rate-limit-* http response headers in Recurly SDK exceptions

[dzenyu]

Describe the bug

Recurly APIs always return the x-rate-limit-* HTTP header responses, as can be seen below:

* Request completely sent off
< HTTP/2 200
< date: Tue, 08 Oct 2024 15:57:32 GMT
< content-type: application/json;charset=utf-8
< content-length: 1716
< etag: W/"52a52dcc05dba5ec7d45aaf4aba84a74"
< server: nginx
< x-robots-tag: noindex, noarchive
< recurly-version: recurly.v2021-02-25
< x-ratelimit-limit: 15000
< x-ratelimit-remaining: 14203
< x-ratelimit-reset: 1728403320
< vary: Accept
< cache-control: max-age=0, private, must-revalidate
< x-request-id: 8bb098df-ee56-4104-a558-0a2aea03c643
< via: 1.1 google
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

When we encounter a rate limit, the Recurly Java SDK client maps this error to RateLimitedException or TooManyRequestsException as rightfully so.

The problem is that neither of these 2 exceptions includes the most important x-rate-limit-* values in the HTTP response.

Enhancement Request

Include the x-rate-limit-* HTTP response header values as part of the Recurly exception classes so that when RateLimitedException or TooManyRequestsException are thrown.

We need the x-rate-limit-* HTTP response headers to help us fine-tune our retry policy by effectively implementing backoff strategies when the rate limit is reached.

To Reproduce

Steps to reproduce the behavior.

Call any GET API after you have been rate limited and you will get either RateLimitedException or TooManyRequestsException.

Expected behavior

Acceptance Criteria - Conditions of Satisfaction

1. The x-rate-limit-* HTTP response values are included in Recurly exception classes such as RateLimitedException or TooManyRequestsException
2. The x-rate-limit-* are populated with the respective values in the HTTP response.

Your Environment

• Latest version
• Sandbox and production environments