[FEATURE] provider option to reject flag set with invalid rules

Moved to FEATURE as discussed below.

Observed behavior

When using a flag config that does not conform to the schema, flagd shows the following warning in the logs but accepts the config nevertheless without error:
2024-12-19T10:26:53.980+0100 warn evaluator/json.go:114 flag definition does not conform to the schema; validation errors: 1:flags.is-enabled: Must validate one and only one schema (oneOf) 2:flags.is-enabled.variants.off: Invalid type. Expected: number, given: boolean 3:flags.is-enabled: Must validate all the schemas (allOf)

This leads to inconsistent behavior during evaluations (https://github.com/open-feature/flagd/issues/1481)

Expected Behavior

There are a couple of behaviors that could make sense:

• when flag config validation fails, return an error and don't accept the updated config, essentially keep working with whatever was already in the flag store (preferred)
• possibly, accept only parts of the config that conform to the schema and return a warning / error (probably not a good idea)

Steps to reproduce

Use the following flag config. The variants have mismatched types (number and boolean).

{
    "$schema": "https://flagd.dev/schema/v0/flags.json",
    "flags": {
      "is-enabled": {
        "defaultVariant": "off",
        "state": "ENABLED",
        "targeting": {
          "if": [
            {
              "<": [
                {
                  "%": [
                    {
                      "var": "request_id"
                    },
                    1000
                  ]
                },
                100
              ]
            },
            "on",
            "off"
          ]
        },
        "variants": {
          "on": 1,
          "off": false
        }
      }
    }
  }

Start at evaluator/json.go:114 and trace the provider config-update path involved in the behavior described in issue 1481. Define how the provider option handles schema validation, with the preferred behavior retaining the previous valid flag store when validation fails; done means the supplied invalid configuration is rejected consistently and the existing configuration remains usable.