feat: pass Dictionary to flag evaluation

[fabriziodemaria]

Behaviour

• Only Dictionaries are allowed as default value when trying to evaluate a complex value
• All the default value keys and their type must be found in the remote schema, otherwise it's a failed evaluation
  • The remote flag can have more keys than the default value Dictionary: those will be ignored and not part of the returned value (makes it safe to add fields to the flag definition later)
  • The opposite is not true: if the default value has a key that is not found in the remote flag, the entire evaluation fail
  • If any field from remote is null, whatever default value defined for that field is returned (regardless of its type ⚠️ )
• On failed evaluations, always return whatever default value was passed in
• If using OpenFeature, the custom OpenFeature.Value is required a default value.
  • The same semantics on keys/types mapping applies

Supported complex types

✅ defaultValue: ["size": 0] # Dictionary
❓ defaultValue: DefVal(size: 0) # struct (see wip. Could we expose this too, eventually?)
❌ defaultValue: ["size": ConfidenceValue.init(integer: 0)] # Dict with ConfidenceValue
❌ defaultValue: ConfidenceValue.init(structure: ["size": ConfidenceValue.init(integer: 0)]) # ConfidenceValue

Address #190

[nicklasl]

First off; great work taking this on and pushing through! And 👏 for writing such detailed tests, really helped me!

Secondly; I'm a bit mixed with all of this. It just becomes a bit less type safe than what I would like when you might get back a Dict<String, Any>. However; in those cases that was actually exactly what you passed in, so maybe it's fine?

I would have suggested we went straight to custom Struct support but we do need this to comply with OpenFeature though so 🤷.
Somewhere in my review I left a comment about the case when we have an additional key in the default value and that "breaks" the flag evaluation. If we could allow that, I'd be all good with this.

[nicklasl]

I am not sure about this behaviour TBH.
Why am I as a user of the SDK not allowed to have other dict keys in the default values compared to what Confidence assigns?
As a developer, this would prevent me from evolving my feature (or how I am using the feature flag) before implementing the new schema in Confidence.

[fabriziodemaria]

Here is a potential pitfall with the mixed approach: if we have a remote variant { "size": 3 } and a default value { "sze": 10 } (with a typo), there would be no evaluation errors and possibly the devs will keep using size 10 around their codebase even if the exposure is for size 3. Not sure how much we should care about this, but it's definitely something more bug prone than failing with: "sze" not found in the remote flag.

[fabriziodemaria]

Another potential pitfall of having certain fields only in the default value is that if we later add the corresponding fields in the remote schema but with a different type we will break existing evaluations. Adding properties to a flag in the UI should always be a "safe operation".

As a developer, this would prevent me from evolving my feature (or how I am using the feature flag) before implementing the new schema in Confidence.

I am thinking devs can still try out the flag locally using the default value. But in order to resolve remote correctly, all the default keys must match the flag's remote schema: perhaps this is a reasonable ask