Support load configuration settings from Azure Front Door

[zhiyuanliang-ms]

Why this PR?

Introduce a new API: loadFromAzureFrontDoor which takes the Azure Front Door endpoint as parameter. The configuration provider will load configuration settings from the Azure Front Door.

Behavior change

When loadFromAzureFrontDoor is used:

1. replica discovery and load balancing features will be disabled.
2. watch request (for refresh) will not be conditional request.
3. authorization header will be removed from the request
4. sync-token will not be attached to the request.
5. Registering watched settings(sentinel key) for refresh is forbidden when connecting to Azure Front Door. With the consistency model of CDN, Sentinel key based refresh may not meet expectation of customers. Only allow collection monitoring based refresh for CDN scenario.

Refresh logic

• Use "x-ms-date response header from AppConfig - this is the time when server generated the response

• The provider will now track the page etags and the x-ms-date of each page response.

• A refresh is triggered only when the refresh engine detects that the page’s ETag has changed and the accompanying x-ms-date is later than the previous server response time. Once a refresh occurs, the system simply reloads whatever content is currently available from the CDN. This means it may temporarily load outdated pages, but because the provider serving the outdated content will still show a detectable change during subsequent refresh checks, the system will eventually update all pages. The underlying philosophy is that a refresh should, at minimum, achieve what an application restart would. Therefore, our refresh mechanism effectively reloads all configuration settings.

[avanigupta]

Suggested change

	REPLICA_DISCOVERY_NOT_SUPPORTED = "Replica discovery is not supported when loading from Azure Front Door.",
	REPLICA_DISCOVERY_NOT_SUPPORTED = "Replica discovery is not supported when loading from Azure Front Door. To leverage AppConfig replicas, add multiple replicas to your Front Door origin group. Lear more about [Origins and origin groups in Azure Front Door](https://learn.microsoft.com/en-us/azure/frontdoor/origin?pivots=front-door-standard-premium).",

[zhiyuanliang-ms]

This error message is too long. And I am not a fan of putting the doc link here.

Instead of pointing to AFD doc, I think the link should be pointed to one doc maintained by ourselves.

[avanigupta]

This is a concept owned by AFD, we dont have any doc on this topic. When we choose not to support it ourselves, it’s important to provide users with any available alternatives. I agree its long, but its necessary in this case.
We can reduce the text to:

"Replica discovery isn’t supported via Azure Front Door. To use AppConfig replicas, add multiple replicas to your Front Door origin group. Learn more: https://learn.microsoft.com/en-us/azure/frontdoor/origin"

[avanigupta]

cc @jimmyca15 If you agree, we should update the error message in .net provider too.

[zhiyuanliang-ms]

This is a concept owned by AFD, we dont have any doc on this topic. When we choose not to support it ourselves, it’s important to provide users with any available alternatives. I agree its long, but its necessary in this case. We can reduce the text to:

"Replica discovery isn’t supported via Azure Front Door. To use AppConfig replicas, add multiple replicas to your Front Door origin group. Learn more: https://learn.microsoft.com/en-us/azure/frontdoor/origin"

I mean we can a doc that teach people how to use AFD with app config or a section of FAQ. Our doc can reference this AFD doc. We should have the full control of the doc.

[avanigupta]

Suggested change

	LOAD_BALANCING_NOT_SUPPORTED = "Load balancing is not supported when loading from Azure Front Door.",
	LOAD_BALANCING_NOT_SUPPORTED = "Load balancing is not supported when loading from Azure Front Door. To load balance between AppConfig replicas, add multiple replicas to your Front Door origin group. Lear more about [Origins and origin groups in Azure Front Door](https://learn.microsoft.com/en-us/azure/frontdoor/origin?pivots=front-door-standard-premium).",

[avanigupta]

Same here, I can make my suggestion shorter:

"Load balancing isn’t supported via Azure Front Door. To load balance across AppConfig replicas, add multiple replicas to your Front Door origin group. Learn more: https://learn.microsoft.com/en-us/azure/frontdoor/origin"

[avanigupta]

Reminder to update this to match .NET provider (add afd tag to "Features")

[avanigupta]

If the header is not a valid date, we should use the default value

[avanigupta]

I mean we need to handle the case if new Date(header) throws an error

[zhiyuanliang-ms]

new Date(header) will not throw. It will become an invalid date. But I should handle the invalid case. Updated

[zhiyuanliang-ms]

If the header is not a valid date, we should use the default value

What should be the default value, undefined or new Date() (current time)?

[zhiyuanliang-ms]

Decide to use new Date() current time to make it consistent as .NET provider

[avanigupta]

lastServerResponseTime will never be null or undefined right?

[zhiyuanliang-ms]

True. If the header is not found, we set it as the current time. Now I am leaning to if the header is not fond, we set the pageWatcher.lastServerResponstTime as undefined.

[avanigupta]

This can be simplified if lastServerResponseTime is always defined

if (serverResponseTime >= lastServerResponseTime && 
    page._response.status === 200 && 
    page.etag !== pageWatchers[i].etag) 
{
    return true;
}