Allow users to specify their own client implementation used by the library

[nikola-jokic]

This pull request enhances the configurability of the HTTP client by introducing new options for setting request timeouts and allowing the use of a custom retryable HTTP client.

Using custom client allows users to specify transport options that will be used as a base.

Fixes #64
Fixes #60

[Copilot]

Pull request overview

This PR improves HTTP client configurability by introducing a configurable request timeout and an option to supply a custom retryablehttp.Client, enabling users to bring their own transport settings as a base.

Changes:

• Added timeout to httpClientOption with a default of 5 minutes and a new WithTimeout option.
• Added support for injecting a custom retryablehttp.Client via a new HTTP option.
• Made proxy assignment conditional on proxyFunc being set.

Comments suppressed due to low confidence (1)

common_client.go:129

• When a custom retryablehttp.Client is provided, retryClient.HTTPClient.Transport may be nil (meaning http.DefaultTransport) or a non-*http.Transport implementation. The current type assertion will fail and return an error, preventing use of custom clients. Consider handling nil by defaulting to a cloned http.Transport (e.g., from http.DefaultTransport) and either supporting non-*http.Transport by skipping transport mutations or documenting/validating this constraint up front.

	transport, ok := retryClient.HTTPClient.Transport.(*http.Transport)
	if !ok {
		// this should always be true, because retryablehttp.NewClient() uses
		// cleanhttp.DefaultPooledTransport()
		return nil, fmt.Errorf("failed to get http transport from retryablehttp client")
	}

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

New behavior is introduced via WithRetryableHTTPClint (custom retryable client) and WithTimeout, but common_client_test.go doesn’t currently cover these option paths. Adding unit tests would help ensure timeouts are applied as intended and custom-client handling (including transport/TLS/proxy interactions) doesn’t regress.

[Copilot]

WithRetryableHTTPClint appears to be a misspelling of WithRetryableHTTPClient. Since this is a new exported API, it’s worth correcting now (and updating the struct comment on line 81) to avoid permanently shipping a typo in the public surface.

Suggested change

	func WithRetryableHTTPClint(client *retryablehttp.Client) HTTPOption {
	// WithRetryableHTTPClient sets a custom retryable HTTP client for the Client.
	func WithRetryableHTTPClient(client *retryablehttp.Client) HTTPOption {

[Copilot]

WithTimeout currently only affects the built-in client path; when o.retryableHTTPClient is provided, o.timeout is ignored and the provided client's HTTPClient.Timeout is left unchanged. Given the PR description (“new options for setting request timeouts”), consider applying o.timeout to the provided client as well (or clearly documenting that WithTimeout is ignored when a custom retryable client is supplied).

Suggested change

	retryClient.RetryWaitMax = o.retryWaitMax
	retryClient.RetryWaitMax = o.retryWaitMax
	}
	// Apply timeout to the underlying HTTP client regardless of whether a
	// custom retryable client was supplied or a new one was created.
	if retryClient.HTTPClient != nil {

[Copilot]

This function mutates the transport (and potentially TLS settings) on the retryablehttp.Client instance passed in via WithRetryableHTTPClint. If callers reuse the same client/transport elsewhere, this can cause unexpected cross-component side effects and can race with concurrent use. Consider cloning the http.Transport (and possibly the http.Client) before applying library-specific settings, or explicitly documenting that the passed client will be modified and must not be shared.