convert procedure result to JSON with consistent scalar representations

[hallettj]

Implements bson_to_json which mostly works as an inverse of json_to_bson. This replaces the bson library's stock serialization implementation which outputs a variation of extjson. We don't want to output extjson (which includes inline type tags) because we keep type information out-of-band, and using extjson would prevent output scalar values from matching input formats despite showing the same scalar types in the graph configuration.

I want to apply the same output conversion to normal query responses. That will be in another PR.

I set up round-trip serialization testing to check for consistency between bson_to_json and json_to_bson. The way it is implemented round-trips do not work with heterogeneous data (cases where we infer a type of Any at any position). So I configured the round-trip test to avoid those cases. An alternative is to output extjson in cases where we show the type as Any so we can losslessly convert back and forth - but that has a trade-off where representations would be inconsistent at different parts of the structure. I'm planning to write up a document to discuss the best way to handle this. Per our discussions I'll change the representation for Any to extended JSON.

For the moment round-trip testing is failing with Datetime and Decimal128 types and possibly some others. I intend to fix that before merging this PR. I fixed these. Round-trip tests caught a bug in Datetime conversion, and I added a normalization step when generating arbitrary Decimal128 values.

Ticket: https://hasurahq.atlassian.net/browse/MDB-95

[dmoverton]

As discussed, we should use Extended JSON for values with type Any.

[hallettj]

@dmoverton I disabled Undefined outputs from arb_bson because those were failing round-trip tests. Using undefined as the bottom type for unifying object field types is logical. But it does mean that we lose undefined as a distinct type when it appears in arrays with other types. For example one of the round-trip test cases that failed was the bson value [null, undefined]. After conversion to json and back we get [null, null] because type unification of null and undefined yields the type null. In my experience with javascript semantics I think "missing object field" is a sensible "bottom" case, while undefined itself is a unit type like null. But it does seem like the difference probably doesn't matter in 99% of cases.

[dmoverton]

@dmoverton I disabled Undefined outputs from arb_bson because those were failing round-trip tests. Using undefined as the bottom type for unifying object field types is logical. But it does mean that we lose undefined as a distinct type when it appears in arrays with other types. For example one of the round-trip test cases that failed was the bson value [null, undefined]. After conversion to json and back we get [null, null] because type unification of null and undefined yields the type null. In my experience with javascript semantics I think "missing object field" is a sensible "bottom" case, while undefined itself is a unit type like null. But it does seem like the difference probably doesn't matter in 99% of cases.

Yeah I've been wanting to create a more canonical type representation to use, at least while we're doing inference and type unification. It would have its own bottom type. We would then convert into the current Type representation only when inference is done and we want to serialize the types.

[dmoverton]

Looks good

[hallettj]

I'll merge this once the round-trip test is fixed

[dmoverton]

@hallettj I'm happy for you to merge this now