Added support for AppConfig Feature Flag profiles

[sandbrock-nd]

Added support for AppConfig Feature Flag profiles by allowing the consumer to nest the resulting JSON in a named parent node.

Description

This aims to allow consumers to inject feature flags into their application. The user cannot control the schema for AppConfig Feature Flag profiles because they are controlled by AWS. The JSON format is like this:

{"test-flag-1":{"enabled":false},"test-flag-2":{"enabled":true}}

This is not friendly with the .NET builder.Configuration system because there is no named wrapper node around the list of feature flags. The result is that each flag is nested directly under the root of the configuration hierarchy.

This update allows the consumer to pass in the name of a wrapper node to nest the AppConfig JSON inside of by using the extension method for AppConfig registration:

    builder.Configuration.AddAppConfig(new AppConfigConfigurationSource()
    {
        ApplicationId = "application",
        EnvironmentId = "Default",
        ConfigProfileId = "my-appconfig-feature-profile",
        AwsOptions = new AWSOptions(),
        ReloadAfter = new TimeSpan(0, 0, 30),
        WrapperNodeName = "FeatureFlags"
    })

And then read the values from that configuration profile, by deserializing the JSON into a dictionary of feature flag class instances:

builder.Services.Configure<Dictionary<string, AppConfigFeatureFlag>(builder.Configuration.GetSection("FeatureFlags"));

Motivation and Context

The end goal is to allow the consumer to inject feature flags into their controllers and minimal API class constructors, such as in the following:

MyConstructor(IOptionsMonitor<Dictionary<string, AppConfigFeatureFlag>> featureFlags)

This addresses the following feature request:
#228

Testing

Initial testing was done by creating a unit test. Follow-up testing was done by integrating the library into an application that consumed both configuration profiles and feature flag profiles. The tests validated both profiles loaded correctly and were injected into the services DI container.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license