Refactor SessionCredentials

[emmyzhou-db]

What changes are proposed in this pull request?

This PR refactors the SessionCredentials class to achieve clearer separation of concerns by splitting its responsibilities into two distinct components: a CredentialsProvider implementation and a dedicated TokenSource implementation. This refactoring is necessary for introducing token cache wrappers in future PRs.

Current Implementation

• SessionCredentials both implements CredentialsProvider and extends RefreshableTokenSource.
• Token refresh logic is tightly coupled with credential provider functionality, making it hard to isolate token source logic and introduce caching.
• A single class is responsible for both authentication configuration and token management.

Proposed Changes

• SessionCredentials now implements only CredentialsProvider and delegates all token operations to a new SessionCredentialsTokenSource class.
• SessionCredentialsTokenSource extends RefreshableTokenSource and is solely responsible for token refresh logic.

Benefits

• Token sources can now be easily wrapped with caching mechanisms in future updates.
• SessionCredentials remains a public CredentialsProvider as intended with no breaking changes to the public API.

How is this tested?

Existing unit tests.

NO_CHANGELOG=true

[renaudhartert-db]

Can we AutoValue this and use an auto value builder?

[emmyzhou-db]

After some reading up, it seems like AutoValue does not support constructors that call parent constructors with arguments: https://stackoverflow.com/questions/45069608/autovalue-how-to-call-super. In this case, we need super(token) in the constructor, so I have opted for removing the builder class and just have the two optional fields as Optional.

[renaudhartert-db]

SG, thanks @emmyzhou-db

[parthban-db]

Where is the sessionCredentials used now? I am seeing all its usages are changed to sessionCredentialsTokenSource. Maybe I am missing something.

[emmyzhou-db]

Where is the sessionCredentials used now? I am seeing all its usages are changed to sessionCredentialsTokenSource. Maybe I am missing something.

So SessionCredentials is not used internally as a CredentialsProvider, but based on the examples from https://github.com/databricks/databricks-sdk-java/blob/main/examples/spring-boot-oauth-u2m-demo/src/main/java/com/databricks/sdk/RootController.java it seems like the intention is that a user can get a SessionCredentials and set it as the CredentialsProvider to use.

[parthban-db]

LGTM modulo Renaud comments.

[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: 470
• Commit SHA: 4b9a4037a3d3424dd2be7ed83a07e1ed897b3c82

Checks will be approved automatically on success.

[renaudhartert-db]

SG, thanks @emmyzhou-db