Add NodaTime scalar types

[benmccallum]

Original repo:
https://github.com/shoooe/hotchocolate-nodatime

Tasks:

• Bring over src + tests.
• Better support for StrawberryShake via custom scalars
• Validate conformity with existing codebase.
• Approve new public API.
• We have type name overlaps, but I've used the HotChocolate.Types.NodaTime namespace to keep them separate. Do we need to consider anything else? Can't imagine folks would want to use current + nodatime versions at once, but would they be able to with type renaming easily enough?
• Type descriptions are nodatime type descs. That's ok, but it's nice in HC's ones how they refer to standards where appropriate so you know the format. Maybe we should do that + link to nodatime docs in the descs?
• Think about docs. Currently I've brought over the original README.md
• Think about crediting the original author. I've added a note at top of the readme for now.
• Get package ownership in NuGet.
• CI (including code coverage?)
• CD.
• ⚠️ ⚠️ Add shoooe as co-author in the merge commit so he gets cred there too.
• Deprecate existing package versions on NuGet? Assuming we'll version this as 11.x, but as long as it supports 11.0 onwards that should be ok.
• Deprecate existing repository (PR over there to point over here, then get shoe to archive it?)

[benmccallum]

@tobias-tengler , what do you think about documenting this? In a similar way to how extended scalars was documented? We just tabulate the readme in here in the docs?

[tobias-tengler]

@tobias-tengler , what do you think about documenting this? In a similar way to how extended scalars was documented? We just tabulate the readme in here in the docs?

Yes, I think that would be best for now.
Personally I think it would be better, if we could get it to integrate into the HotChocolate.Types.Scalars package. That would be the most seamless in my opinion (from a usage as well as documentation persective). We could call them something likeNodaDateTimeZone for example to avoid the name collisions.

[benmccallum]

I considered that too @tobias-tengler; the concern I had is that then we force someone to take on a dependency they might not want/need (NodaTime). That might be acceptable though.

[benmccallum]

@michaelstaib , one thing I'm wondering about is how to elegantly do the custom scalar ISerializer that StrawberryShake integration would benefit from.

It seems a shame to need to copy/link the code of the core scalar type's TryDeserialize implementation over in to another project like StrawberryShake.Types.NodaTime. It's a problem that I imagine we should solve for all the existing extended scalars too though.

Any thoughts on how we should approach it?

[shoooe]

I've added ChilliCream as package owner. 👍

[shoooe]

I've also added a warning in the README of the old repository and archived it.

[tobias-tengler]

@benmccallum I will go over this more thoroughly tonight. I think we should have another look together tomorrow. We should add for strawberry shake a separate issue otherwise this will take to long. The StrawberryShake serializers can go into 11.4 or 12.

@tobias-tengler do we want to put docs into this PR or a separate one.

@shoooe what is your GitHub email that we can use for the commit?

I can convert the documentation in the README to the website real quick. I just hope it doesn't get to full ^^

[sonarcloud]

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
5 Code Smells

78.5% Coverage
3.8% Duplication

[michaelstaib]

I think we are ready.

[michaelstaib]

I ticked Better support for StrawberryShake via custom scalars since it is out of scope for this PR.... lets create an issue for that. We have a couple of other serializers to introduce and can do that together with that effort.

[michaelstaib]

@benmccallum what is Approve new public schema. about?