Ensure Cached Access Token Value is Used

[andremleblanc]

It's possible for there to be multiple access tokens in use even with the cache, I believe this is because we don't check for a different access token value before creating a new one in refresh!

Steps to Reproduce
I discovered this be having the access token env set and comparing the cached value between a worker and console.

1. Have HELP_SCOUT_ACCESS_TOKEN set.
2. Open a console.
3. Run something in the background that calls Help Scout, check access token.
4. Run something in console that calls Help Scout, check access token.
5. Compare results.
   1. The cache should have the token from the background job.
   2. Subsequent background jobs will use the cached token.
   3. The console will use a different token that the cached value.

[andremleblanc]

Spoke with @jcypret a bit about this one. The example above illustrates a way to get two processes using the gem out-of-sync which results in them bashing each other's tokens whenever one is invalidated.

Possible Solutions
Disable Access Token Config
This might be the only way to get them out-of-sync, but I doubt it. If it were, and maybe either way, we should remove this option.

Check Cache Before Refreshing
Before we create a new token, we should check to see if the cache has a valid token different than what is memoized in this process. I think the main challenge here would be determining if the cached token is valid - just because it's within it's expiration date doesn't mean it's invalid.

Check the Cache More Often
Currently, we essentially memoize the value on the process level. Alternatively, we could memoize on the request level, checking the cache between requests. One challenge here would be a race-condition where multiple requests refresh the token at the same time. Though this would be eventually-consistent, it's not ideal (locking may be a possible solution).

cc @prsimp