…after new token stored or old token deleted

Currently the token store unlock occurs directly after the token refresh call completes, but prior to the new token being stored or the old token being deleted.  In situations with a high volume of asynchronous calls occurring leading up to the token refresh flow initiating, a race condition can occur upon token store unlock whereby a subsequent token refresh call that was queued then immediately retrieves the previous refresh token from the unlocked token store before the new refresh token has had a chance to be written to the token store.
The resulting token refresh API call attempt using a burnt/no longer valid refresh token results in a 400 level error (e.g. 'invalid_grant' ) from the OAuth2 identity server.

…shared call

- Removed some `self` references
- Added comment