[FEATURE] ResolutionDetails improved typing for error cases.

[toddbaert]

Requirements

Improve typings of EvaluationDetails and ResolutionDetails by forcing the addition of errorCode if reason = ERROR.

[mowies]

shouldn't this be the other way around? if error code is error, then you need a reason for the error code?

[toddbaert]

@mowies I see why you'd think that, but in the semantics of the SDK, the REASON field is not a REASON for an error. It's the reason that the resolution proceeded the way it did.

For example, if a flag evaluated to true because it's defined statically as true, than the provider can set the REASON to STATIC. If the flag evaluated to true because a certain targeting rule was hit, that would be TARGETING_MATCH. See the table from the spec here. REASONs are something like HTTP status codes, which can indicate both success and error, but their main purpose is to communicate the why. Similarly to HTTP status code, they can be extended, but a limited list of pre-defined reasons is shipped with SDKs.

This issue is to force the population of errorCode if Reason === Error, which is something the spec recommends: https://docs.openfeature.dev/docs/specification/sections/flag-evaluation/#requirement-148