Refactor all tests that use LitJson to use System Text Json

[peterrsongg]

Description

This updates all tests to use system.text.json so that we can eventually remove the litJSON dependency. System.Text.JSON is much more strict on what it can parse, so I had to add a SanitizeJson method that sanitizes the jsonstring before trying to parse so that the tests don't blow up. I also had found 2 issues with the event stream tests in core. One is that the test was previously looking for header as the json property name when it should've been looking for headers, because of this none of the asserts were actually being triggered. After changing that I uncovered a bug in the Byte header, where the test was sending back a signed byte but we were expecting it to be an unsigned byte. I plan to fix this in an upcoming PR b/c it doesn't seem like a simple fix.

Motivation and Context

Eventual removal of LitJSON as a dependency.

Testing

Dry run passes, also manually stepped through each changed test to make sure it was running as expected. By doing this I found 2 issues with event stream tests as described in the description.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[boblodgett]

How bad of a performance hit is the SanitizeJson? It already tried to parse it once, then gets a regex performance hit, before another performance hit trying to parse it again.

[peterrsongg]

I didn't measure the performance hit, but without the sanitize, the parsing of the message will just fail if the json is invalid. My way of guarding against this potential performance reqression every time was to do the try catch so that we only sanitize if we fail. I believe I put this in here b/c there was a failing test without it, but let me double check to see if I can remove it and the test passes. If so, I will just remove it here but if not maybe the test itself needs to be looked at again.

[peterrsongg]

I ended up just fixing the test case which was missing a comma, and removing the sanitize call here. Since the json will come from the service, we shouldn't have to sanitize the message.