REST resource state persisting between job/request executions within the same thread

Issue summary

By default, rails applications in production will not reload constants & classes between requests or
between execution of background jobs. This means that certain data stored within class instance variables on the REST
resources (see the base resource here)
will not be reset when a given thread completes processing a request or job, and begins to process another.

To illistrate where this could be an issue, consider a simple class that might be used throughout an application to
fetch product information for a Shop:

class FetchProducts
  class << self
    def call
      return if rate_limit_reached?

      ShopifyAPI::Product.all
    end

    private

    def rate_limit_reached?
      limits = ShopifyAPI::Product.api_call_limit

      return false unless limits.is_a?(Hash) && limits[:request_count] >= limits[:bucket_size]

      true
    end
  end
end

If no prior Product API calls have been made within the context of current job or request, it would be reasonable
to expect ShopifyAPI::Product.api_call_limit to be nil since we haven't made a request yet, and therefore there have
not received a response with any rate limiting headers.

However since api_call_limit is stored within a class instance variable within the ShopifyAPI::Product class,
if the current thread has previously processed a separate request or job that used the ShopifyAPI::Product
class to fetch products, then the response headers from that prior request will stil be present in the class.

It's entirely possible that this prior job or request pertained to an entirely separate shop, and thus the stored
rate limit headers would not be applicable within our current job / request.

The implication of this, is that it's not safe to check values stored in the class instance state of the REST resources until after a request has been made through that same class.

Start by reading the REST resource state handling in lib/shopify_api/rest/base.rb, especially the linked lines 125-153. Determine how class instance state persists across requests or jobs, then define a reset or isolation point so state from an earlier execution, including another shop, is not reused before a new request.