feat: internal to Standard JSON Schema conversion COMPASS-8700

[paula-stacho]

Very similar to $jsonSchema. The difference is that instead of mapping the internal types to bsonType, we map it to JSON Schema.
This is done so that it fits the Relaxed Extended JSON definition - it will be either

• one of the basic JSON Schema types
• refer to a definition describing the relaxed extended JSON

The definition are mostly taken from @mcasimir's POC, I checked them with specs and made several updates:

• binary subtype pattern changed from ^[0-9a-fA-F]{2}$' to `^[0-9a-fA-F]{1,2}$' (it says "BSON binary type as a one- or two-character hex string" in the specs)
• removed maximum on timestamp t&i (I just don't see it in the specs)
• 'Infinity', '-Infinity', 'NaN' are not direct values, but wrapped in{ $numberDouble: ... }

TODO:

• highlight the small differences from wip: export schema dialog compass#5690
• add tests

[Anemy]

Couple small things, looks good, looking at the tests now

[mcasimir]

silly NIT comment, (but is your fault for tagging me in the PR description :)), from an external PoV, even having read the scope, it took me a while to link "standard" here to the distinction between the non-standard mongodb-specific json schema, and the standard json schema. I wonder if after some time will pass from this project this context would be even more hard to get.

How about we add a comment to explain this distinction, or maybe a more boring name that carries the context within itself something like toStandardEJSONJsonSchema vs toMongodbJsonSchema? Totally non blocking, please feel free to ignore!

[paula-stacho]

Not sure about the naming, but I'm adding JSDoc descriptions to the top level functions (in the accessor)

[mcasimir]

non-blocking NIT: do we want to include all of the definitions, even for types that aren't used? Omitting some would make the schema easier to read, not sure if is worth to do that though.

[mcasimir]

is this valid json schema? i thought here you need

"anyOf": [
    { "type": "integer" },
    { "type": "string" }
  ]

please ignore if that compact form is also possible.

[paula-stacho]

The compact form is possible as long as it's plain types (no extra properties or refs)

[mcasimir]

Thanks @paula-stacho! I left few random comments.

Would it also make sense to load ajv in our tests and validate the schema that we produce against the json schema meta-schema? To make sure that we are effectively producing a valid json schema, and that we would keep doing so even after changes to the code?

[paula-stacho]

Thanks @paula-stacho! I left few random comments.

Would it also make sense to load ajv in our tests and validate the schema that we produce against the json schema meta-schema? To make sure that we are effectively producing a valid json schema, and that we would keep doing so even after changes to the code?

Good idea, adding this validation!

[Anemy]

Looking good, I left a couple comments on types. A few questions to help my understanding as well

[Anemy]

nice!