Marten: Support System.Text.Json

[lahma]

This is the new JSON library from Microsoft, which concentrates on performance (speed and minimal allocations).

• Try the new System.Text.Json APIs
• How to serialize and deserialize (marshal and unmarshal) JSON in .NET

I did a quick trial of integrating via ISerializer abstraction and some findinds.

ISerializer API

Marten has following contract https://github.com/JasperFx/marten/blob/master/src/Marten/ISerializer.cs
whereas JsonSerializer has a bit different kind of expectations https://docs.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializer?view=netcore-3.1

• JsonSerializer also supports async operations, should the ISerializer inteface have ValueTask based methods?
• JsonSerializer expects Spans or Utf8Reader/Writer, the current TextReader and strings might not be optimal
  
  
  
  • Utf8Reader/Utf8Writer might be a good abstraction for a stream?
  
  
• Current constructs could probably be replaced with Spans and ArrayPool & friends
• Some public configuration properties might not belong here, maybe should only be part of Customize calls with concrete type target?

Configuration

• Would probably need to make serializer selection mandatory, if both JSON.NET and System.Text.Json were supported out of the box (see pitfalls if automatically transitioning between the two)

Some pitfalls (I've found so far)

• System.Text.Json is strict by default
  
  
  
  • case-sensitive, doesn't allow quoted booleans etc
  
  
  • all these conform to the official spec, but might cause trouble - some can be configured, some not
  
  
• Might be viable only to start with this library from the beginning in a new Marten project, migration later might be hard
• Cannot create immutable classes with private/protected/internal setters ( https://github.com/dotnet/corefx/issues/38569 , https://github.com/dotnet/corefx/issues/38163 )

[Miggleness]

Related to #885

[mysticmind]

My thinking is to hive off the Json.NET serializer as a seperate assembly. This way, Marten library does not have a direct dependency on Json.NET. Also potentially reducing diamond dependency issues.

Once this is done, it makes it easier for implementing and wiring other serializers including unit tests.

Since these are breaking changes, we have to tackle this in 4.x milestone.

Note that I have already done the work to seperate the Json.NET serializer portion and will plan to send a PR when we start dev work on 4.x.

[jeremydmiller]

@mysticmind I'm going to disagree with splitting the Newtonsoft serializer support off the main lib. Having the Newtonsoft support out of the box gives us a very quick getting started story.

[mysticmind]

@jeremydmiller I agree with your point of view on the ease of getting started but my primary impetus to hive off was around reducing diamond dependency issues.