feat: enable pre-emptive async oauth token refreshes

[igorbernstein2]

The current implementation of oauth refresh offloads the IO to a separate executor, however when a token expires, all calls to getRequestMetadata would hang until the token is refreshed.
This PR tries to improve the situation by adding a stale state to token. If a token is within a minute of expiration, the first request to notice this, will spawn a refresh on the executor and immediately return with the existing token. This avoids hourly latency spikes for grpc.

The implementation uses guava's ListenableFutures to manage the async refresh state. Although the apis are marked BetaApi in guava 19, they are GA in guava 30

• The class introduces 3 distinct states:
  • Expired - the token is not usable
  • Stale - the token is useable, but its time to refresh
  • Fresh - token can be used without any extra effort
• All of the funtionality of getRequestMetadata has been extracted to asyncFetch. The new function will check if the token is unfresh and schedule a refresh using the executor
• asyncFetch uses ListenableFutures to wrap state: if the token is not expired, an immediate future is returned. If the token is expired the future of the refresh task is returned
• A helper refreshAsync & finishRefreshAsync are also introduced. They schedule the actual refresh and propagate the side effects
• To handle blocking invocation: the async functionality is re-used but a DirectExecutor is used. All ExecutionErrors are unwrapped. In most cases the stack trace will be preserved because of the DirectExecutor. However if the async & sync methods are interleaved, it's possible that a sync call will await an async refresh task. In this case the callers stacktrace will not be present.
• Special care is taken to make sure that the lock is released when the token is being refreshed

[codecov]

Codecov Report

Merging #646 (a17186e) into master (292e81a) will decrease coverage by 0.35%.
The diff coverage is 79.13%.

❗ Current head a17186e differs from pull request most recent head a5a5a47. Consider uploading reports for the commit a5a5a47 to get more accurate results

@@             Coverage Diff              @@
##             master     #646      +/-   ##
============================================
- Coverage     83.59%   83.23%   -0.36%     
  Complexity      606      606              
============================================
  Files            42       42              
  Lines          2712     2797      +85     
  Branches        289      299      +10     
============================================
+ Hits           2267     2328      +61     
- Misses          303      320      +17     
- Partials        142      149       +7     

Impacted Files	Coverage Δ	Complexity Δ
...google/auth/oauth2/ExternalAccountCredentials.java	91.60% <0.00%> (-6.16%)	29.00 <0.00> (ø)
...java/com/google/auth/oauth2/OAuth2Credentials.java	82.87% <84.61%> (+0.01%)	39.00 <25.00> (+1.00)
..._http/java/com/google/auth/oauth2/AccessToken.java	78.94% <0.00%> (-10.53%)	10.00% <0.00%> (-1.00%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 469b160...a5a5a47. Read the comment docs.

[igorbernstein2]

Note to reviewer: before this PR, the blocking version getRequestMetadata() was the primary codepath, so ExternalAccountCredentials only had to override that method. This subclass expected that the async version would just call the sync version. Which I think is a poor assumption since its an implementation detail. I corrected the behavior by overriding both.

Arguably a better approach is to make both getRequestMetadata final and have subclasses use asyncFetch() as the source of truth, but I didn't want to leak guava to the surface of this library

[TimurSadykov]

Overall looks good, lets clarify if refresh slight behavior change is blocking.

Some coverage of refreshTask would be great.

[igorbernstein2]

Thanks for reviewing! I think addressed all of your comments, PTAL

[paulmordont]

Hey @igorbernstein2 ! Thx a lot for the PR, from my side everything looks good. Looking forward to testing this in the next bigtable client release :)

[TimurSadykov]

Looks good to me, but please let's make sure @silvolu also take a look before merge.

[lesv]

I'm reviewing this w/ @Neenu1995 and am just getting started, but given that you mention that you are potentially changing behavior, I wonder if there is a way to bring this change back into Google3 and run all the tests that blaze will invoke to see if this is safe?

[igorbernstein2]

I created cl/373364841, I had to hand edit a couple of irrelevant files:

• added missing RunWith on unrelated tests
• added missing deps in BUILD

I requested a global tap presubmit

Also, I updated the codestyle suggestions from critique