feat(java): Add Auto Refresh

[alexr-bq]

Summary

• Add ElastiCacheIamAuthTokenManager for lazy token caching and background refresh.
• Share a single token mint across concurrent callers and reuse cached tokens while valid.
• Retry transient refresh failures with jittered exponential backoff while continuing to serve a valid token.
• Complete shared refresh state on fatal failures and rethrow Errors so later token requests can recover.
• Add token-change callbacks, credential-pair access, close semantics, and TokenRefreshException for operational failures.
• Update the Lettuce example, Java documentation, changelog, and installed-artifact API coverage.

Verification

• 42 Java unit tests passed.
• Maven clean install, Javadocs, and dependency analysis passed.
• Documentation examples compiled successfully.
• Installed-artifact public API integration test passed.

[edlng]

could you set the base to point to #10 so its easier to view the diff? Or even better I think if you try the new Github stacked PRs feature, it will automatically have the base point back to main once #10 is merged

[alexr-bq]

Done

[mwaisaida-13]

This only catches RuntimeException, if provider.getToken() throws an Error (e.g. NoClassDefFoundError from a classpath mismatch), this catch doesn't fire and the future is never completed, so inFlight stays set and every later getToken() hangs in join(). On the executor thread it's also swallowed silently: ScheduledFuture captures it and we discard that future. Could we catch Throwable, complete the future exceptionally, and rethrow Errors?

[alexr-bq]

Fixed — refresh now catches Throwable, completes the shared future so inFlight is cleared, and rethrows Errors unchanged.

[mwaisaida-13]

One thing here, the callback runs on commonPool(), which the whole application shares (as few as one thread on a small host), and callbackExecutor isn't public, so a customer with a slow onTokenChanged (e.g. re-authenticating many connections) can stall unrelated work with no way to opt out.

We'd like all three languages to behave the same here: run the callback on the manager's own refresh thread, right after the token is installed and the lock is released, still off the caller's path, but on a thread we own. Suggestion: drop the executor and call onTokenChanged.accept(token) directly at the end of installAndComplete (outside synchronized), keep the try/catch, and note in the Javadoc that the callback should return quickly since it delays only the next refresh. Open to discuss this

[alexr-bq]

Addressed. onTokenChanged now runs on the manager's own single refresh thread after the token is installed, the refresh is completed, and the lock is released.