What?

Add optional, configurable HTTP retries for Web API calls so the client can automatically retry on rate limits (429), server errors (5xx), and connection failures (e.g., connection reset), improving reliability when Slack is under load or the network is flaky.

• 429: Under load, Slack may return 429. Library users currently have to implement their retry and Retry-After handling.
• 5xx: Transient server errors are common; retrying with backoff often succeeds.
• Connection errors: Temporary network issues (connection reset, refused, EOF) are good candidates for retry.

Without built-in retry, every application must add its own logic, and they may not handle Retry-After or body replay correctly. Centralizing this in the client keeps behavior consistent and avoids duplicate code.

It also will align retry behavior with the Python Slack SDK (rate limit, server, and connection error handling).

Proposed solution

• Opt-in: New options OptionRetry(maxRetries int) and OptionRetryConfig(RetryConfig). Retries are off by default, so existing behavior is unchanged.

• RetryConfig: MaxRetries; for 429: RetryAfterDuration, RetryAfterJitter (and use Retry-After when present); for 5xx/connection errors: BackoffInitial, BackoffMax, BackoffJitter. Provide DefaultRetryConfig() with sensible defaults.