Support instantiating different API clients, and advanced HTTP configuration

[foca]

This PR allows you to use Tarpon to target multiple different RevenueCat Projects from within the same codebase.

Our use case is probably uncommon, but we have a backend that supports multiple different mobile apps, each with its own RevenueCat configuration, as a different Project in RC. This means different API keys, and at that point Tarpon is not able to work, since the configuration happens in a singleton object (the Tarpon::Client class).

This changes the library so that it now instantiates Tarpon::Client and calls methods on the instances, rather than calling singleton methods on the class:

config.project_1.revenue_cat = Tarpon::Client.new do |c|
  c.public_api_key = ENV['PROJECT_1_REVENUE_CAT_PUBLIC_KEY']
  c.secret_api_key = ENV['PROJECT_1_REVENUE_CAT_SECRET_KEY']
end

config.project_2.revenue_cat = Tarpon::Client.new do |c|
  # ...
end

In order to preserve backwards compatibility—and to support the common use case of just needing to target a single RevenueCat project, this also introduces a Tarpon::Client.default instance to which all methods are delegated.

This allows users to continue using the same API, but provides the flexibility to target different projects if needed.

This also provides a new API to configure clients, by passing properties to Client.new. This makes it easy for use in e.g. Rails, where you might want to use something like config_for to load different configurations from a YAML file.

Finally, this extends the configuration to allow a Proc to be passed to configure the HTTP.rb requests made under the hood, to enable any and all features of that library, such as instrumentation, proxy usage, or granular timeouts:

Tarpon::Client.new do |c|
  c.http = ->(http) do
    http
      .use(instrumentation: { instrumenter: ActiveSupport::Notifications.instrumenter })
      .via(ENV['PROXY_URL'], ENV['PROXY_PORT'])
      .timeout(read: 5, write: 5, connect: 1)
  end
end

At first I considered adding specific instrumentation options (which is our more immediate need), but I though providing access to the HTTP requests might be a bit more flexible, since it keeps the API surface small (only one extra setting) while giving users a lot of power to tweak the requests.

However, this does make the dependency on HTTP.rb part of the public API of the library, so if, in the future, Tarpon desires to move away from HTTP.rb, that would require a major version change as it would be a breaking change. WDYT?

[foca]

bump? It's been a couple months :)

[blasut]

@foca hey, thanks for the PR I'll review this later today

[blasut]

Thank you so much for contributing to Tarpon!

Very well written PR. We just have a couple of comments around naming.

[foca]

Thanks for your thoughtful review, @blasut. ❤️

[igorbelo]

Hi @foca,

First of all thanks for contributing to Tarpon and sorry for the super slow response.
I'll make sure to address any questions you may have as soon as possible so we get it off the ground.

As you said your use case is probably not common but I don't believe it's a reason not to support it anyway, as long as we don't break the current API.

I've left a few comments around configuration, felt a little confused having multiple ways to do so, would like to hear your thoughts about it. I'm all for deprecating .configure in the future though and go with the natural way of instantiating in Ruby.

Have a great one.

[igorbelo]

Thanks again for your contribution @foca, I'll be making sure the changes work well in production before releasing it.

[igorbelo]

Released in v0.5.0.