[node-core-library] Include support for parsing JSON files with object keys that are reserved words and fix an issue with JSON schema validation.

[iclanton]

Summary

With the upgrade to use ajv for JSON schema validation, we accidentally introduced a regression where using the "uniqueItems": true option in a schema for an array with items that are objects causes an exception to be thrown when calling JsonFile.loadAndValidate. This is because the jju parses JSON files by default does not populate the functions from Object.prototype on parsed JSON objects and ajv uses a.valueOf() === b.valueOf() as part of its deep comparison of objects (via the fast-deep-equal package). The valueOf function isn't populated on objects, so this function call fails.

This PR adds the reserved_keys: 'replace' jju parse option to populate these functions. This also allows parsing of objects with these properties. This introduces an edge case where a JSON object with a "valueOf" key will fail with a similar error in a similar scenario, but this is a much less common case than the currently-broken functionality.

How it was tested

Introduced tests for these scenarios.

[octogonz]

JJU's behavior is absolutely bizarre. I assumed they were trying to protect against this kind of mistake:

The compiler catches the above case, but neither the compiler nor our lint rules catch [key] access like this:

Approach #1: A sensible protection would be to delete the prototype so that JSON parsed objects don't have this problem. That's what I thought JJU was doing. @iclanton noted that it breaks ajv's object analysis however, which doesn't expect deleted prototypes.

Approach #2: What JJU is actually doing: It deletes the prototype but also discards actual keys using reserved names. This results in inexplicable data loss:

Approach #3: The replace behavior enabled by this PR is to correctly parse keys like "constructor", allowing the them to shadow the prototype property of the same name. Nothing is actually "replaced", it's just shadowed according to normal JavaScript prototype inheritance.

Empirical experimentation shows that Approach #3 is used by JSON.parse() as well as these 3 highly popular parsing libraries:

• json5
• yaml
• js-yaml

Therefore despite the pitfalls of JavaScript, I agree that PR #4736 is the best and most conventional way to go.