Add pluggable HTTP transports

[jnunemaker]

Summary

• introduce a registry-backed HTTParty::Transport contract with normalized request, response, and streaming chunk objects
• extract the existing Net::HTTP execution path into the default HTTParty::Transport::NetHttp backend
• add an optional HTTParty::Transport::Curl backend powered by curb, selectable with transport :curl
• add opt-in persistent Net::HTTP connection pooling and explicit client lifecycle cleanup
• document transport registration, selection, lifecycle, supported Curl options, and known semantic differences

Why

HTTParty's request pipeline was coupled directly to Net::HTTP response and connection behavior. That made an optional libcurl backend difficult without requiring it to impersonate Net::HTTP.

This introduces a whole-request transport boundary while keeping redirects, cookies, authentication, parsing, logging, decompression, and response policy in HTTParty. Net::HTTP remains the default and continues to honor the existing connection_adapter contract.

User impact

Existing clients continue to use Net::HTTP without configuration changes.

Curl is opt-in and does not add a runtime dependency:

# Gemfile
gem "curb"

class Client
  include HTTParty
  transport :curl
end

Third-party transports can register a short name with HTTParty::Transport.register. Class-owned transport instances are reusable and close through Client.close; request-level overrides are closed after the request.

The Curl backend rejects unsupported Net::HTTP-specific options instead of silently degrading behavior. Its timeout and request-upload buffering differences are documented.

Validation

• mise x ruby@3.1.1 -- ruby -Ilib -S rake
• RSpec: 846 examples, 0 failures
• Cucumber: 36 scenarios, 186 steps, all passing
• real libcurl loopback integration covering named selection and HTTParty-managed redirects
• git diff --check