Refactor Token Caching with CachedTokenSource Wrapper

[emmyzhou-db]

Changes

This PR refactors the token refresh and caching in the Java SDK by:

• Removing the RefreshableTokenSource class that previously handled token refresh and caching logic directly
• Introducing CachedTokenSource as a generic wrapper that can be applied to any TokenSource implementation
• Separating concerns by moving caching and async logic out of individual token sources into a dedicated cache wrapper

Motivation

Previously, token sources inherited from RefreshableTokenSource to gain caching and asynchronous refresh capabilities. However, this inheritance-based approach had limitations when we wanted to make configuration immutable after construction using the builder pattern.

The Problem: With abstract classes in Java, constructors are not inherited. To support builder-based configuration, each token source subclass would need to be modified to accept a builder instead of individual parameters, requiring changes across many classes.

The Solution: Switch from inheritance to composition. Instead of inheriting caching behavior, we now wrap any TokenSource which previously inherited from RefreshableTokenSource with CachedTokenSource to add caching functionality externally. This allows us to use the builder pattern to configure optional parameters like async refresh and stale duration on each wrapped instance.

How is this tested?

This change has been tested with async enabled/disabled by default on existing unit and integration tests.

NO_CHANGELOG=true

[parthban-db]

Mostly LGTM. Left a small comment.

[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-java

Inputs:

• PR number: 461
• Commit SHA: 663801aea959cb3b74429d4ea5e582d053cc505f

Checks will be approved automatically on success.