fix(auth/m2m): remove double-caching to enable proactive token refresh

[aausch]

Summary

Fixes a double-caching bug in M2M OAuth that caused the proactive async token refresh to have no effect, resulting in bursts of HTTP 401 errors at each token rotation boundary (~every hour).

Closes #1549.

Why

M2mCredentials.Configure previously called clientcredentials.Config.TokenSource(ctx), which returns an oauth2.ReuseTokenSource. That source was then passed to refreshableVisitor, which wraps it in a cachedTokenSource. The resulting stack is:

cachedTokenSource          ← Databricks async cache (proactive, T-20min)
    └── authTokenSource    ← discards context
            └── oauth2.ReuseTokenSource  ← Go stdlib cache, expiryDelta=10s
                    └── clientcredentials.tokenSource  ← HTTP /token endpoint

When cachedTokenSource triggers its async refresh at T−20 min, it calls through to ReuseTokenSource.Token(). Because the token still has 20 minutes of life, ReuseTokenSource considers it valid and returns the cached token without an HTTP call. The async refresh fires repeatedly (with an accelerating schedule) but each call hits the same inner cache — until only ~10 s remain, at which point ReuseTokenSource's expiryDelta window is crossed and a real network call is finally made.

Any request that receives the about-to-expire token and whose round-trip to Databricks completes after the token's expiry time gets HTTP 401. In production this manifests as a burst of 401s at precisely one-hour intervals, correlated with pod startup times.

What changed

Interface changes

None.

Behavioral changes

• M2M OAuth token refresh now makes a real HTTP call to the token endpoint at T−20 min (the intended proactive window) rather than at T−10 s.
• Callers will see one additional token endpoint call per hour per process (the proactive refresh), offset by eliminating the burst of 401s at expiry.

Internal changes

• auth_m2m.go: replaced clientcredentials.Config.TokenSource(ctx) (which returns a ReuseTokenSource) with a TokenSourceFn closure that calls ccfg.Token(ctx) directly. cachedTokenSource is now the sole caching layer.
• cache_test.go: added reuseTokenSource test helper and two new tests:
  • TestCachedTokenSource_AsyncRefreshBlockedByInnerCache — documents the double-caching behaviour using a mock clock.
  • TestCachedTokenSource_AsyncRefreshWithDirectSource — verifies that a direct (non-caching) inner source triggers an HTTP fetch at the proactive window.
• NEXT_CHANGELOG.md: updated.

How is this tested?

• TestCachedTokenSource_AsyncRefreshBlockedByInnerCache: uses a fake clock and a controlled reuseTokenSource helper to confirm that inner caching delays the HTTP fetch to T−10 s rather than T−20 min.
• TestCachedTokenSource_AsyncRefreshWithDirectSource: uses the same fake clock with a direct token source to confirm the fetch occurs at T−20 min after the fix.
• Existing TestM2mHappyFlow and TestM2mHappyFlowForAccount continue to pass.

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-go

Inputs:

• PR number: 1550
• Commit SHA: b68a94111be2de295c84599c275bdc4ff3827d02

Checks will be approved automatically on success.