Fix the token audiences of aztables for sovereign clouds

[xumou-ms]

• The purpose of this PR is explained in this or a referenced issue.
• The PR does not update generated files.
  • These files are managed by the codegen framework at Azure/autorest.go.
• Tests are included and/or updated for code changes.
• Updates to module CHANGELOG.md are included.
• MIT license headers are included in each file.

[github-actions]

Thank you for your contribution @xumou-ms! We will review the pull request and get back to you soon.

[Copilot]

Pull Request Overview

This PR fixes incorrect token audiences for Azure Tables in sovereign clouds (Azure China and Azure Government). The audiences are being standardized to use https://storage.azure.com across all clouds, instead of cloud-specific domains.

• Updated cloud configuration to use the correct global storage audience for sovereign clouds
• Updated tests to validate the corrected audience behavior
• Added CHANGELOG entry documenting the bug fix

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
sdk/data/aztables/cloud_config.go	Changed audiences for AzureChina and AzureGovernment from cloud-specific domains to the global storage.azure.com
sdk/data/aztables/service_client_test.go	Updated test expectations to validate the corrected storage audiences for sovereign clouds
sdk/data/aztables/CHANGELOG.md	Added bug fix entry for incorrect token audiences in sovereign clouds

Comments suppressed due to low confidence (1)

sdk/data/aztables/service_client_test.go:491

• [nitpick] While storage audiences now use the global domain, Cosmos endpoints still use cloud-specific audiences (.cn and .us). Consider adding a comment explaining why Cosmos and storage have different audience patterns to prevent future confusion.

			endpoint: "https://myAccountName.table.cosmos.windows.net",
			scope:    "https://cosmos.azure.cn/.default",

[richardpark-msft]

This change doesn't quite make sense to me, but I might not be understanding the actual bug.

Basically, we have three audiences set, for the three different clouds in your PR. For instance, 'https://storage.azure.cn' for AzureChina.

The service client will then check to see if the endpoint you're using has a Cosmos suffix - if so, it'll just do a simple string replace, and you'll end up with 'cosmos.azure.cn'. In your change it appears you're just hardcoding that to always be Cosmos, which (I assume) will now break customers that want to use Azure Tables, but in Storage in different clouds.

I'm curious if the bug is actually in here:

azure-sdk-for-go/sdk/data/aztables/service_client.go

Line 317 in 4af5cf4

return isCosmosEmulator || strings.Contains(url, cosmosTableDomain) || strings.Contains(url, legacyCosmosTableDomain)

where we try to determine if your endpoint is for Cosmos, or for Storage. We're searching for these two: ".table.cosmosdb." or ".table.cosmos.". Does that match your endpoint?

[jhendrixMSFT]

Fixes #25542

[richardpark-msft]

@xumou-ms, if you can merge in the two suggested comments then we should be good to go.

[xumou-ms]

Thanks to @jhendrixMSFT @richardpark-msft for reviewing this PR! I merged in the two suggested comments

[richardpark-msft]

@xumou-ms, thanks for the PR!