Allow passing arbitrary `HTTParty` options in `ShopifyAPI::Clients::HttpClient`

Start with lib/shopify_api/clients/http_client.rb, especially HttpClient#request and the initializer described in the issue. Confirm that arbitrary HTTParty options can be supplied while the existing headers, query, and body behavior remains intact, and verify the resulting request behavior with the project's HttpClient tests.

Overview

ShopifyAPI::Clients::HttpClient internally uses HTTParty to perform HTTP requests, but there is currently no way to pass through any HTTParty options (e.g. timeout, open_timeout, read_timeout, etc.). HttpClient#request hardcodes only headers, query, and body when calling HTTParty.send(...).

https://github.com/Shopify/shopify-api-ruby/blob/8c72cd222d346472a29e51c7a7dfb6b7239f7456/lib/shopify_api/clients/http_client.rb#L51-L57

It would be helpful if HttpClient allowed passing an arbitrary set of HTTParty options, rather than only supporting specific ones, so that users can configure whichever options they need without waiting for the gem to add explicit support for each one.

Problem

Because none of HTTParty's other options are exposed, users of this gem have no way to bound request latency with timeout / open_timeout / read_timeout (e.g. for background jobs or requests with strict SLAs). Currently the only workaround is monkey-patching HttpClient, which is fragile across gem upgrades.

Proposed Solution

Rather than adding support for a single option like timeout, it may be more flexible to allow passing an arbitrary options hash that gets merged into the HTTParty call, e.g.:

sig { params(base_path: String, session: T.nilable(Auth::Session), httparty_options: T::Hash[Symbol, T.untyped]).void }
def initialize(base_path:, session: nil, httparty_options: {})
  @httparty_options = httparty_options
  # ...
end

# in #request
res = T.cast(HTTParty.send(
  request.http_method,
  parsed_uri.to_s,
  **@httparty_options.merge(
    headers: headers,
    query: request.query,
    body: ...,
  ),
), HTTParty::Response)

This would let users pass timeout:, open_timeout:, read_timeout:, or any other HTTParty-supported option, without the gem needing to explicitly enumerate and support each one individually.

Alternatives Considered

• Adding a dedicated timeout: argument only — simpler, but doesn't generalize to other HTTParty options users may need.
• Monkey-patching HttpClient — works today but fragile across gem upgrades.