Adds default http targeting context accessor

[rossgrambo]

Why this PR?

1. Addresses issues a. https://github.com/microsoft/FeatureManagement-Dotnet/issues/415 b. https://github.com/microsoft/FeatureManagement-Dotnet/issues/399
2. Also makes HttpContext.Items cache consistent- so all classes check the same location.

Next Steps:

1. Remove unremarkable HttpTargetingContextAccessors from examples in favor of DefaultHttpTargetingContextAccessor.
2. Consider a different cache pattern that doesn't rely on a shared string key.

Visible Changes

Developers will now have a new type available to them, DefaultHttpTargetingContextAccessor. Instead of defining their own, they can use this type when adding targeting via WithTargeting like:

builder.Services.AddFeatureManagement()
    .WithTargeting<DefaultHttpTargetingContextAccessor>()

The default accessor will extract the targeting info from HttpContext.User. Groups will be extracted from claims of type Role. UserId is taken from the Identity.Name field.

[rossgrambo]

If someone has an idea for a shared place for the TargetingContextLookup string, let me know. I couldn't decide on a clean spot. Decided to leave them as separate strings for now since we're hoping to adjust the caching to not need them anyway.

[zhenlan]

Just for ideas... you either make it a public property or use InternalsVisibleToAttribute between the two packages. Like you said, none of them are clean ways.

[jimmyca15]

I know adding a scoped service will be an approach that we will want to propose to float the resolved targeting context along, but I also thing we should consider an alternative option -- exposing a public extension method on HttpContext from the Microsoft.FeatureManagement.AspNetCore package that gets the resolved targeting context.

namespace Microsoft.FeatureManagement.AspNetCore;

public static class HttpContextExtensions
{
    //
    // Gets the targeting context resolved by feature management during a request.
    public static TargetingContext GetTargetingContext(this HttpContext httpContext);
}

[zhiyuanliang-ms]

@jimmyca15 @rossgrambo Are we going to include this PR into the next preview release (preview3)?

[rossgrambo]

Would be nice- but I don't think it's a blocker.

[zhiyuanliang-ms]

Is there a plan to use this built-in targeting context accessor in our FeatureFlagDemo example? (include the change in this PR or create a new PR after this PR is merged?)

[rossgrambo]

Is there a plan to use this built-in targeting context accessor in our FeatureFlagDemo example? (include the change in this PR or create a new PR after this PR is merged?)

Yes, I'm planning on a separate PR to update examples.

[jimmyca15]

There have been some developments as we have discussed the middleware and telemetry initializer across different PRs/issues. My expectation at this point is that:

• The middleware moves to the same project as the initializer
  • If we stick to http context items cache, the key is project internal
• The default targeting context accessor uses a cache key that is not accessible outside
  • private object _targetingContextKey = new object();

As such, I don't expect any changes in the middleware/initializer as part of this PR.

[rossgrambo]

As such, I don't expect any changes in the middleware/initializer as part of this PR.

Agreed. This PR is on hold until the caching rework is completed.

[rossgrambo]

This PR has been dissolved into two:

• https://github.com/microsoft/FeatureManagement-Dotnet/pull/466 - Add DefaultTargetingContextAccessor to main
• https://github.com/microsoft/FeatureManagement-Dotnet/pull/467 - Adjusts targetingId caching to use Activity