ServiceTokens are created on each Connection.request when the unexpired may still be available in the ServiceTokenProvider

[leisurehound]

Is your feature request related to a problem? Please describe.

The latency of repeated requests (at least to Sheets API) is non-trivial, as it appears on each request a new token is requested. This likely results in extra unnecessary bandwidth consumption for devices and delays in the user experience.

Describe the solution you'd like

If the current token is unexpired, it should be returned. Additionally, if a request comes in before an imminently expiring token an asynchronous process should be kicked off to refresh it. Alternatively, upon creation of a token schedule a refresh slightly before token expiry.

Describe alternatives you've considered

See above for two possible solutions.

Additional context

I will craft a PR for one of the alternatives shortly.

[rasberik]

@timburks @leisurehound
Sorry for sudden late message, I just noticed this when updating from release version to main branch, and it broke some of my code.
I am writing regarding this PR: #57 which is addressing the issue here.

I think the PR violates some code consistency in terms of single responsibility principle and doing too much (useful for some general use cases, but not for others).
I would suggest to keep ServiceAccountTokenProvider more agnostic if possible. I can prepare PR in that direction, but that would mean that expiration check code will not be concern of TokenProvider anymore.