Use of cloud configurations

[RickWinter]

Before GA we need to review the endpoint configurations to ensure we are compatible across clouds. We don't need to implement 1550 as long as we are future proofed to do so in 1.1.

Azure/azure-sdk#1550

Tasks:

• Identify all current cloud endpoint uses (add list to this issue)
• Verify all instances are customizable by the user

[antkmsft]

KeyVault KeyClient uses hardcoded "https://vault.azure.net/" scope - could be a problem when using token credential.
In other aspects, it uses vault URL - so should be no problem pointing it to other clouds.

Storage uses StorageScope that is hardcoded to "https://storage.azure.com/" - for TokenCredential this might be problem.
Their credential can parse different endpoint from connection string.
Clients seem to take URLs, so in that way it should be possible to use other clouds (with storage credential, for token credential - I don't think it is currently possible).

So, storage and keyvault might have same problems.
At the same time, they are constructible from URL - so tit is possible for them to detect the cloud that they are being initialized for, and to create BearerTokenAuthenticationPolicy with the correct scope.

So, work likely needs to be done to make them work in national clouds, but it shouldn't be API-breaking, and so can be done post-GA.

More info on the private cloud endpoint URLs: https://docs.microsoft.com/en-us/azure/azure-government/compare-azure-government-global-azure

[antkmsft]

And other language SDKs have the same public API.

[antkmsft]

The thing being proposed for the future, would basically translate to ClientOptions having a parameter for Cloud/WellKnownCloud. I do not think anything blocks us to add that in the future.