Add retry policy configuration

[coolguy1771]

Proposal

The current retry mechanism is too rigid for production environments, lacking support for exponential backoff, jitter, and custom retry logic. I propose moving to a more robust RetryPolicy configuration to better handle transient failures and prevent "thundering herd" issues.

Proposed Interface

This structure allows for fine-grained control over the backoff strategy and retry conditions:

type RetryPolicy struct {
    MaxRetries      int
    InitialInterval time.Duration
    MaxInterval     time.Duration
    Multiplier      float64
    Jitter          bool
    // ShouldRetry allows for custom logic (e.g., retrying specific 5xx codes but not 4xx)
    ShouldRetry     func(resp *http.Response, err error) bool
}

func WithRetryPolicy(policy RetryPolicy) HTTPOption {
    return func(c *httpClientOption) {
        c.retryPolicy = policy
    }
}

Implementation Presets

var (
    AggressiveRetry = RetryPolicy{
        MaxRetries:      10,
        InitialInterval: 100 * time.Millisecond,
        MaxInterval:     30 * time.Second,
        Multiplier:      2.0,
        Jitter:          true,
    }
    
    ConservativeRetry = RetryPolicy{
        MaxRetries:      3,
        InitialInterval: 1 * time.Second,
        MaxInterval:     10 * time.Second,
        Multiplier:      2.0,
        Jitter:          true,
    }
    
    NoRetry = RetryPolicy{MaxRetries: 0}
)

Benefits

• Resilience: Better handling of transient network or API issues.
• Flexibility: Allows users to opt-out of retries for sensitive operations.
• Safety: Jitter prevents synchronized retry spikes that can trigger secondary rate limits.