[vNext] System.Text.Json as default serialization mechanism

[ealsur]

This PR works on replacing Json.NET as the default serialization mechanism in the SDK. While Json.NET can still be used through an implementation of CosmosSerializer (like the current one for V3) all REST API contracts, and item operations (CRUD and Queries) will use System.Text.Json by default.

In this PR:

• All Public REST API classes use System.Text.Json converters
• The internal default serializer is https://github.com/Azure/azure-cosmos-dotnet-v3/blob/1e6a86c50d70520deadb4a5dd07df878b3fdc138/Microsoft.Azure.Cosmos/azuredata/Serializer/CosmosTextJsonSerializer.cs
• Some files that were previously linked to the V3 versions have now been unlinked and new versions created. This was needed to de-couple from Json.NET contracts, for example, Spatial types such as LineString.
• Emulator and Unit Tests that relied on Json.NET serialization comparisons were adjusted to use System.Text.Json instead
• Deserialization of classes coming from Microsoft.Azure.Cosmos.Direct, such as OfferV2 and Error are using Converters that get added to the serializer, such as https://github.com/Azure/azure-cosmos-dotnet-v3/blob/1e6a86c50d70520deadb4a5dd07df878b3fdc138/Microsoft.Azure.Cosmos/azuredata/Serializer/TextJsonOfferV2Converter.cs because the source code of those classes is not available to be decorated.

This PR closes #73 and closes #1111

[j82w]

Should we use CosmosElements instead? That way we could support hybrid row or other encoding types in the future.

[ealsur]

This is a System.Text.Json converter, and it works through the System.Text.Json.JsonConverter decorator, plus the input classes (reader) is System.Text.Json, why would I add CosmosElements? I'd argue that CosmosElements actually is very very similar to JsonDocument, and I'm not sure if it should be replaced

[j82w]

The agruements I have for switching to CosmosElements are:

1. It's a clean interface that abstracts away the serializer implementation. This will prevent all the pain if we need to convert to a different serializer in the future.
2. It supports the different content format like hybrid row.

For the actual implementation for CosmosElements it would probably be best to just have methods on the classes and avoid the JsonConverters altogether removing all dependencies from System.Text.Json.

[ealsur]

Doesn't CosmosElement depend on Newtonsoft.Json? https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/CosmosElements/CosmosElement.cs, https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/CosmosElements/CosmosElementSerializer.cs

The ask was to actually add the dependnecy of System.Text.Json, if I use CosmosElement instead and remove the dependency, doesn't that go against the ask?

And how does CosmosElement work for write scenarios that require support for different types? Aren't we kind of re-inventing the wheel? I get the reason for CosmosElement in a scenario where we are using Newtonsoft.Json, but since JsonDocument has the same benefit and is maintained by a dedicated team, why would we need to have our own custom thing? Will we evolve at the same speed as a dedicated team? Will we work on performance and produce the same results?

[j82w]

CosmosElement does currently depend on Newtonsoft, but it should be pretty easy to replace it with System.Text.Json. It will also need to be converted eventually since Newtonsoft needs to be removed.

It's more like adding an abstraction to JsonDocument. This way it's a clean interface that is easy to swap. They both have the pros and cons. It's just the amount of energy it is taking to convert the current code base makes me wonder if having the abstraction is worth it to avoid this pain in the future.

[kirankumarkolli]

Thanks alot @ealsur

[KrzysztofCwalina]

@ahsonkhan
@ericstj