[FEATURE] Update flagd-core, RPC and OFREP Evaluations to Support `null` or Undefined `defaultValue`

[toddbaert]

Requirements

We want to support null/undefined defaultValue in flag configurations. See Parent issue for full details.

Steps

• Update JSON evaluator to return FLAG_NOT_FOUND for configurations missing a defaultValue and for which targeting doesn't resolve a variant (This is the critical behavioral change)
• Make sure OFREP and RPC handlers behave accordingly.

[aepfli]

I might have missed that in the ADR, but I am not sure if FLAG_NOT_FOUND is the appropriate reason. This could lead to confusion, where it looks like there is an issue with flag data propagation. Should we maybe use an own reasoning, or utilize DEFAULT?

[toddbaert]

I might have missed that in the ADR, but I am not sure if FLAG_NOT_FOUND is the appropriate reason. This could lead to confusion, where it looks like there is an issue with flag data propagation. Should we maybe use an own reasoning, or utilize DEFAULT?

@aepfli As we discussed, we are somewhat constrained in our choices here due to historical reasons. flagd responds FLAG_NOT_FOUND for INACTIVE flags, and protocols we use such as OFREP can't convey "this flag exists and is disabled" for all RPCs, so for overall coherence and consistency, we are opting to treat flags with no defaultValue as FLAG_NOT_FOUND (or more concisely, you could say that since a flag value is a required part of a flag, if you can't resolve a value you effectively have no flag).

[Rahul-Baradol]

Can I pick this :)