No touch NEW-region support

[kirankumarkolli]

Goals:

• New Cosmos region can be consumed by SDK with-out SDK upgrade
• Region names: Support even canonical names also (ex: IMDS)
• Remove RegionProximity code paths from SDK

Non-goals:

• SDK Regions public contract update (It can be late bound)

Discussion:

• Remove RegionProximity code paths from SDK
  1. Impacts ApplicationRegion API => Mapping will be dynamic and service driven
  2. GlobalEndpointManager fallback (in-case of main endpoint unavailability)

CosmosClient will be initialized with only the account endpoint (Almost all cases except custom region names).
In-case the endpoint is not available then currently preferredRegions are used to fall-back to regional endpoints.

=>
(1) Can be solved by overloading some existing API's.
(2) GlobalEndpointManager fallback: can't be on the account endpoint.

Account independent global cosmos endpoint for account discovery is ideal.
Popular Global endpoints strategies are DNS based (ex: Azure traffic manager or plain DNS records). Even these are meant for usage at-scale where in SDK case it needs to be guaranteed.

In any case, behind that global endpoint, there will be instances globally distributed across regions for each cloud.

For first phase of MVP, SDK can start with seed of such instances (ex: 5/7 seeds for public cloud) and for non-public cloud an API to configure.