Add schema tests (#1260)

[gjvoosten]

These tests pass against 3.0.4 as well as 3.0.5.

[stevehu]

Yes, the root cause of the issue described in GitHub Issue #1260 #1260 is a set of syntax errors in the
user's JSON Schema that were previously ignored silently in v3.0.4 but are correctly rejected in v3.0.5 .
──────

Root Cause Analysis

1. Misplacement of allOf inside properties

In the user's schema:

"questions": {
  "properties": {
    "allOf": [
      { "$ref": "#/$defs/questions" },
      { "assessmentDate": "#/$defs/question" },
      { "expirationDate": "#/$defs/question" }
    ]
  }
}

Because "allOf" is defined inside the "properties" block of "questions" , the validator treats "allOf" as a property name rather than the JSON Schema allOf
keyword.

According to the JSON Schema specification, the schema for any property under "properties" must be a valid JSON Schema (which can only be a JSON object or a
boolean). Because the value of the "allOf" property here is an array ( [...] ), the validator throws:

│ SchemaException: Schema at […]/allOf must be object or boolean but was ARRAY

2. Invalid Subschema syntax

Furthermore, inside the array, they wrote:

{ "assessmentDate": "#/$defs/question" }

This is also invalid JSON Schema syntax (it is an object using a custom property key assessmentDate with a string value, rather than a proper {"$ref": ...}
schema object).
──────

Why it worked in v3.0.4 but fails in v3.0.5

• In v3.0.4 : The library did not validate loaded schema node types at compilation/load time. Because the input JSON never actually contained a property named
"allOf" , the validator never had to run validation on it, and the schema compiled without crashing.
• In v3.0.5 (introduced by PR #1250): The library added strict compile-time validation of loaded schemas in SchemaRegistry.validateSchemaNodeType . This ensures
that schemas are structurally valid when compiled. Since the value of the property "allOf" is an array, the validator correctly rejects it with a SchemaException
during initialization.
──────

How to Fix the Schema

The user's schema should be corrected to place allOf as a sibling keyword of properties rather than nesting it inside, and specify the subschemas correctly:

 "questions": {
-  "properties": {
-    "allOf": [
-      {
-        "$ref": "#/$defs/questions"
-      },
-      {
-        "assessmentDate": "#/$defs/question"
-      },
-      {
-        "expirationDate": "#/$defs/question"
-      }
-    ]
-  },
+  "allOf": [
+    {
+      "$ref": "#/$defs/questions"
+    },
+    {
+      "properties": {
+        "assessmentDate": {
+          "$ref": "#/$defs/question"
+        }
+      }
+    },
+    {
+      "properties": {
+        "expirationDate": {
+          "$ref": "#/$defs/question"
+        }
+      }
+    }
+  ],
   "required": [
     "assessmentDate"
   ]
 }

[gjvoosten]

@stevehu Thanks for your thorough analysis. I must admit that that specific part of the JSON Schema draft was always a bit foggy. I've updated the schema in the PR, and the tests now pass against 3.0.4 as well as 3.0.5. Might be worth including these to avoid future regressions. Merge, or close, at your discretion.