Load From Azure Front Door

[zhiyuanliang-ms]

Why this PR?

This feature is targeted on the CDN story.

This PR adds a new API loadFromAzureFrontDoor which allows user to load key values from the Azure Front Door. The Azure Front Door will forward the request to App Config and use managed identity for authentication.

For CDN scenario, the recommended way for dynamic refresh is "watch all". We introduced key value collection monitoring based refresh in #133 .

The implementation is aligned with #601

Visible changes

No conditional request will be sent when CDN is used.

To break cdn cache, we will use a pipeline policy to append query param _=<last-changed-etag> to all the request sending to cdn.

Example:

Initial load - no etag

First watch request - no etag

Change detected:

1. sentinel key change 

All the following refresh/watch request (until new change detected) - sentinel key etag

2. sentinel key deleted

All the following refresh/watchrequest (until new change detected) - SHA256(ResourceDeleted\nprevious sentinel key etag) (Use hash to hide the "ResourceDeleted")

3. page etag change

All the following refresh/watch request (until new change detected) - the first changed page etag

We send different requests to retrieve feature flag and key values

[zhiyuanliang-ms]

I reverted the original commit of adding loadFromCdn (#130) to unblock doing release for EXP telemetry changes.
We still have the issue with supporting dynamic refresh for CDN scenario:

1. You are not guaranteed to get the latest etag of sentinal key because cdn's cache may not expired. During refresh we should force cdn to pull the latest etag.

This PR will contains all changes of the complete solution of loading from cdn.

[Copilot]

Pull Request Overview

This PR introduces a new API (loadFromCdn) to support loading configuration key-values from a CDN while breaking the CDN cache by appending a query parameter based on etag changes. It also refactors internal selector management in AzureAppConfigurationImpl and adjusts related tests and exports to support the CDN scenario.

• Adds loadFromCdn API and its supporting pipeline policy and tests.
• Refactors selector collections in AzureAppConfigurationImpl to handle CDN-specific logic.
• Updates test helpers and exports to integrate and validate CDN behavior.

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
test/utils/testHelper.ts	Updates function signature for load balance mode to pass pages instead of emptyPages.
test/requestTracing.test.ts	Adds tests to verify the CDN tag in the correlation-context header.
test/loadBalance.test.ts	Modifies load balance tests to use the updated API with mocked key-value pages.
test/exportedApi.ts	Re-exports the new loadFromCdn API.
src/requestTracing/utils.ts	Incorporates the new isCdnUsed flag and CDN tag into request tracing header creation.
src/load.ts	Implements the loadFromCdn API and introduces an emptyTokenCredential for CDN requests.
src/index.ts	Updates exported APIs to include loadFromCdn.
src/common/utils.ts	Adds getCryptoModule for cross-environment crypto support.
src/EtagUrlPipelinePolicy.ts	Creates a policy to append an etag query parameter for breaking the CDN cache.
src/AzureAppConfigurationImpl.ts	Refactors selector management and integrates CDN handling into configuration loading.
package.json	Bumps @azure/app-configuration dependency version.

Comments suppressed due to low confidence (2)

src/AzureAppConfigurationImpl.ts:771

• [nitpick] Consider renaming the loop variable 'i' to 'pageIndex' or another more descriptive name to improve code readability.

let i = 0;

src/load.ts:52

• [nitpick] Update the function documentation to clearly explain the purpose of the additional boolean flag (indicating if the empty token credential was used) when calling AzureAppConfigurationImpl.

const appConfiguration = new AzureAppConfigurationImpl(clientManager, options, credentialOrOptions === emptyTokenCredential);

[rossgrambo]

nit- but you don't need to change it since you're following a common pattern.

I just don't like enforcing immutability like this because it makes a shallow copy and I think it makes the code uglier. listOptions is always new in this snippet and not exposed to any other code between construction and this mutation. But I bet a linter would still want to enforce full immutability.

Here's an alternative to avoid the shallow copy while still being immutable, but it's harder to read.

Suggested change

	let listOptions: ListConfigurationSettingsOptions = {
	keyFilter: selector.keyFilter,
	labelFilter: selector.labelFilter
	};
	// If CDN is used, add etag to request header so that the pipeline policy can retrieve and append it to the request URL
	if (this.#isCdnUsed && selectorCollection.cdnToken) {
	listOptions = {
	...listOptions,
	requestOptions: { customHeaders: { [CDN_TOKEN_LOOKUP_HEADER]: selectorCollection.cdnToken }}
	};
	}
	let listOptions: ListConfigurationSettingsOptions = {
	keyFilter: selector.keyFilter,
	labelFilter: selector.labelFilter,
	// If CDN is used, add etag to request header so that the pipeline policy can retrieve and append it to the request URL
	...((this.#isCdnUsed && selectorCollection.cdnToken) && { customHeaders: { [CDN_TOKEN_LOOKUP_HEADER]: selectorCollection.cdnToken }})
	};

or could just ignore "pure immutability" and do (my preference if the linter doesn't complain)

listOptions.requestOptions = { customHeaders: { [CDN_TOKEN_LOOKUP_HEADER]: selectorCollection.cdnToken }};

[rossgrambo]

This line/logic is repeated a lot. Maybe a helper that adds the option if passed a cdnToken would be better?