Provider context type clarification

[beeme1mr]

The FeatureProvider interface uses a map[string]interface{} instead of a EvaluationContext. Was this done intentionally?

This question was asked by @rgrassian-split on Slack.

[james-milligan]

Changes were made following this issue happy to reopen

[james-milligan]

I will add comments to references to make this change seem more intentional

[beeme1mr]

@rgrassian-split, does this make sense to you? Do you have any concerns?

[rgrassian-split]

@beeme1mr I softly disagree and think the provider having to look up the exact string to fetch the targeting key from the map is just as troublesome as / worse than having to make an additional fetch to attributes before accessing custom attributes. It's just a soft disagree though, overall it's pretty minor and fine with either.

[james-milligan]

One benefit to decoupling the 2 types (context passed by the client, and context passed to a provider) is that we can make changes to the client facing api without requiring all providers to be updated with the new types, although this does nto necessarily have to come in the form of the FlattenedContext, and of course if only relevant if the EvaluationContext type is subject to change