Replace Newtonsoft.Json with System.Text.Json

[aaronpowell]

With it built into the .NET framework, there's probably no need to rely on an external package for serialisation/deserialisation of the JSON is there?

[Aniruddh25]

@mbhaskar Could you please sync with Aaron about your need for using Newtonsoft.Json See this opposite issue #60

[VinnieKhanna]

I'd like to make the case against entirely relying on System.Text.Json. While working on stored procedure work, I came across the need to support more customized deserialization from strings to enums. Json converters like Kebab casing and workarounds like specifying with the EnumMember attribute aren't natively supported by .NET.

This issue describes what I'm referring to in detail.

From the developers working on this issue: dotnet/runtime#29975 (comment)

Let me be absolutely clear, providing built-in support for everything is an explicit anti-goal for System.Text.Json. Instead, we aim to provide good extensibility points so that third-party extensions like the one you cited can be successful.

Others echo this sentiment throughout the issue. Point being - I don't think we should remove Newtonsoft if it is serving a valid purpose in our code, as System.Text.Json isn't necessarily meant to be an all-encompassing solution, it seems.

[aaronburtle]

There might be some use cases where changing over doesn't really get us much, if anything, and STJ is missing features which would make doing so overly burdensome. However, the performance differences between the two are large enough that even if using STJ in a particular case is difficult to do, we should aspire to do so anyway. And in particular for those areas where perf testing shows that we get a significant speed up in runtime, or significant drop in memory allocation by using STJ, in my opinion, we should do whatever we can to make that work.

[ayush3797]

@Aniruddh25, does this cover Cosmos as well?