add support for connecting to Azure Front Door with Azure App Configuration store as an origin

[samsadsam]

Usage Patterns

Collection Monitoring Pattern (Recommended)

builder.AddAzureAppConfiguration(options =>
{
    options.ConnectAzureFrontDoor(new Uri("https://your-cdn-endpoint.azurefd.net"))
           .Select("app:*")
           .ConfigureRefresh(refresh =>
           {
               // Monitor entire collection for changes
               refresh.RegisterAll()
                      .SetRefreshInterval(TimeSpan.FromSeconds(30));
           });
});

Sentinel Key Pattern

builder.AddAzureAppConfiguration(options =>
{
    options.ConnectAzureFrontDoor(new Uri("https://your-cdn-endpoint.azurefd.net"))
           .Select("app:*")
           .ConfigureRefresh(refresh =>
           {
               // Register specific keys as sentinels
               refresh.Register("app:sentinel", refreshAll: true)
                      .SetRefreshInterval(TimeSpan.FromSeconds(30));
           });
});

How do we guarantee fresh config when refresh all is triggered?

In the case of when a refresh all is triggered, we add a new token param to the query that essentially triggers CDN to fetch from origin (Azure App Configuration) so that we get the latest configuration. This token is the first change etag we detected, the one that triggered a "refresh all" operation.
It is either a page new etag (Collection Monitoring Pattern) or sentinel key new etag (Sentinel Key Pattern). We treat feature flags the same as collection monitoring.
We keep using this token until a new change happens and a new etag is detected.

[avanigupta]

Note: Correlation-Context header should contain a special tag when ConnectCdn is used.

[avanigupta]

Looks good, the only remaining work is to rename cdn->afd everywhere.

[samsadsam]

Looks good, the only remaining work is to rename cdn->afd everywhere.

I don’t think we need to do this for internal classes, I think cdn is better than afd as we can support other CDN providers in the future with same internal classes.

My understanding is that we only need to do this for the public apis

cc @jimmyca15

[jimmyca15]

Looks good, the only remaining work is to rename cdn->afd everywhere.

I don’t think we need to do this for internal classes, I think cdn is better than afd as we can support other CDN providers in the future with same internal classes.

My understanding is that we only need to do this for the public apis

cc @jimmyca15

If it's easier to understand by linking the two with afd, then I'm fine with it.

[avanigupta]

Looks good, the only remaining work is to rename cdn->afd everywhere.

I don’t think we need to do this for internal classes, I think cdn is better than afd as we can support other CDN providers in the future with same internal classes.
My understanding is that we only need to do this for the public apis
cc @jimmyca15

If it's easier to understand by linking the two with afd, then I'm fine with it.

My thinking is that if we were starting from scratch today, knowing we’re adding a new API called ConnectAzureFrontDoor, and commit to supporting AFD (not generic CDN) - would we still name classes/interfaces with CDN?

[samsadsam]

@avanigupta @jimmyca15 does it look good now?

[zhiyuanliang-ms]

what is the purpose of this testcase?

[zhiyuanliang-ms]

What we really care about is whether both apps can eventually get the latest configuration from the cdn. I understand what this testcase is doing, but I don't think it is meaningful.

[jimmyca15]

Key is no longer guaranteed to be lowercase here.

[zhiyuanliang-ms]

@avanigupta @jimmyca15

Didn't we decide to add the policy of query params normalization to SDK instead of provider?

@mrm9084 has the PR for Java SDK: Azure/azure-sdk-for-java#46665
And I have the PR for JS SDK: Azure/azure-sdk-for-js#35962

[jimmyca15]

Yes, it should be in the SDK.

[zhiyuanliang-ms]

Move to #706