.NET: [Breaking] Allow passing auth token credential to cosmosdb extensions

[SergeyMenshykh]

Motivation and Context

This PR updates CosmosDB-related extension methods, allowing them to accept authentication token credentials instead of using a default one, which may not be deterministic enough for production scenarios.

[Copilot]

Pull request overview

This PR updates CosmosDB extension methods to accept TokenCredential parameters for authentication instead of hardcoding DefaultAzureCredential, providing more flexibility for production scenarios. This is a breaking change as it modifies the method signatures.

Changes:

• Replaced Azure.Identity namespace import with Azure.Core in both extension files
• Added TokenCredential parameter to CreateCheckpointStoreUsingManagedIdentity methods (both generic and non-generic)
• Added TokenCredential parameter to WithCosmosDBMessageStoreUsingManagedIdentity method
• Added null validation for the new tokenCredential parameter in all modified methods

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
CosmosDBWorkflowExtensions.cs	Added tokenCredential parameter to both CreateCheckpointStoreUsingManagedIdentity overloads with validation
CosmosDBChatExtensions.cs	Added tokenCredential parameter to WithCosmosDBMessageStoreUsingManagedIdentity with validation

[lokitoth]

We should also consider letting the user provide a CosmosClient directly; I imagine people building webapps will store more data than just the chat history, and it is likely that they will reuse a CosmosDB account for it, which will likely be configured on DI.

[westey-m]

We should also consider letting the user provide a CosmosClient directly

We actually have a work item (#2982) for this already and @TheovanKraay, who contributed these implementations, said that he can take a look.

[TheovanKraay]

I agree with supporting explicit TokenCredential, but I don't think this needs to be breaking, and would would not want to remove implicit DefaultAzureCredential usage anyway, which this change does. Can it be refactored so existing methods remain and forward to new overloads that accept TokenCredential?

[TheovanKraay]

We should also consider letting the user provide a CosmosClient directly

We actually have a work item (#2982) for this already and @TheovanKraay, who contributed these implementations, said that he can take a look.

I will look at this next week. I agree that is also needed for more complex scenarios than this.

[TheovanKraay]

I agree with supporting explicit TokenCredential, but I don't think this needs to be breaking, and would would not want to remove implicit DefaultAzureCredential usage anyway, which this change does. Can it be refactored so existing methods remain and forward to new overloads that accept TokenCredential?

As discussed, the change does actually make sense, even as a breaking change. Fine for it to be merged.