Reginal endpoint support

[rayluo]

This resolves #295.

Feature wise this is completed.

TODO: Currently the authority validation is still performed. Would need to decide whether that is desirable. CC: @bgavrilMS Now MSAL will ignore connection error during Authority Validation if app developer opted in to use azure_region.

[henrik-me]

http_client

imo, we should have dedicated http client with a shorter timeout for this.

[rayluo]

Having 2 different http clients (one dedicated for region detection and one for the rest), would complicate not just MSAL's internal implementation, but also the API model, which would then propagate to our app developer's implementation. Yet the gain is debatable.

When an http_client has short timeout (say, 2 seconds x 2 retries = 4 seconds latency), those seemingly short latency might go unnoticed, and become a perpetual behavior for that app. (If that app happens to be a command-line app such as Azure CLI, it would mean each "az ..." would have 4+ seconds extra latency.)

The current approach would have a longer latency by default. But hopefully this "fail early, fail loudly" approach would lead customer to a better solution: to make their "region" setting configurable, so that it could (and should) be completely turned off by an on-site configuration, when their app is deployed outside of Azure VMs.

[henrik-me]

This is not a http client dedicated for region, but a client dedicated to fetch data from the imds endpoint. Primary reason is the timeout setting from above.

[neha-bhargava]

Yes, usually imds call fails fast but with the default retry logic it was taking longer to fail making the overall response time longer. So it was decided to set timeout to 2 sec for the imds call specifically with 1 retry.

[rayluo]

My understanding is: (1) if your app is running inside Azure VM (or Azure Function etc., for that matter), the detection is a local http call which would be quick (even quicker than other cross-machine http requests), so customizing timeout would be unnecessary; (2) if your app is running outside of Azure infrastructure, you wouldn't want to waste some latency on a meaningless region detection.

The default longer timeout would cause app developer in scenario No.2 to notice the hanging during their smoke testing, which would then lead them to somehow add a per-deployment flag to opt out of the region behavior when/if their app is not deployed on Azure. After that, their app would be more performant when deployed to production.

[neha-bhargava]

@rayluo agree that there is a need to set the timeout specifically for the imds call to 2 seconds.

[rayluo]

Responded to some review comments. A new commit is on the way.

[rayluo]

My understanding is: (1) if your app is running inside Azure VM (or Azure Function etc., for that matter), the detection is a local http call which would be quick (even quicker than other cross-machine http requests), so customizing timeout would be unnecessary; (2) if your app is running outside of Azure infrastructure, you wouldn't want to waste some latency on a meaningless region detection.

The default longer timeout would cause app developer in scenario No.2 to notice the hanging during their smoke testing, which would then lead them to somehow add a per-deployment flag to opt out of the region behavior when/if their app is not deployed on Azure. After that, their app would be more performant when deployed to production.