Asp.net Core web app doesn't throw any exception when feature flag free quota limit is reached

[jimmyca15]

This is moved from microsoft/FeatureManagement-Dotnet#70 on behalf of @SailleshPawar

Original issue below

---

This is something that we faced in production recently.
Accidentlally we were using Free tier of App Configuration in production workload for our web app.
We were deploying the new changes in the production environment and we were getting 500.30 service unavailable error, when we were trying to access the API's
We tried running the command *dotnet .dll from kudu using dotnet .dll command and it just hangs doesn't show any error in console.
At last we tested on local env and found it was due to feature flag free quota limit is reached application was not running and no exception was shown in console, making it hard to understand what is the root cause of the issue.

below is our code for program.cs

`{

                 var builtConfig = builder.Build();

                 var azureServiceTokenProvider = new AzureServiceTokenProvider();

                 var keyVaultClient = new KeyVaultClient(
                     new KeyVaultClient.AuthenticationCallback(
                         azureServiceTokenProvider.KeyVaultTokenCallback));

                 builder.AddAzureKeyVault(
                     $"https://{builtConfig["KeyVaultName"]}.vault.azure.net/",
                     keyVaultClient,
                     new DefaultKeyVaultSecretManager());

             })

            .ConfigureAppConfiguration((ctx, builder) =>
            {
                var builtConfig = builder.Build();
                builder.AddAzureAppConfiguration(options => {
                    options.Connect(builtConfig["feature-flag-connection-string"])
                        .UseFeatureFlags();
                });
            })`

[zhenlan]

When a store reached the limit and is being throttled, the application will not be able to connect to App Configuration at startup (after retries), so it will throw an exception. The exception should include information on the reason for the failure (being throttled). Given that 500 is observed when the application was running in an App Service web app, the API behaved as expected. In terms of debugging, it's the same experience when an application failed to start in the web app for any other reason.