Library Refactor for DotNet 8 and Signature Version 5

[Bottswana]

Description

This PR represents a significant rewrite of the library to bring it up to modern dotnet core standards.
This includes:

• Uplifting to current c# language level, rewriting some elements into more recommended syntax
• Splitting out the existing signature method into an interface and implementing V4 and V5 of the signature format so we can call more recent API endpoints
• Uplifting the test framework to test these signature methods, using the Python library as a base of "known good" signatures
• Removing platform specific code so the library is able to run platform independent
• Adding XML documentation so IntelliSense/Auto complete in IDE's functions for the library
• Removing many dependancies, so the library now only relies on Newtonsoft for JSON serialisation.
• Start the implementation of API endpoints into the library for the admin API so users of the library can call API methods natively with pre-constructed models. (Currently implemented for User endpoints and Group endpoints)

Motivation and Context

Current library state is not usable in modern DotNet projects as it relies on 4.0 framework.
This closes issues #30 and #33

How Has This Been Tested?

Test suite has been adapted to include test coverage of the library.
Other tests concluded via Examples project.
Additional testing will be required as more endpoints are added.

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)

This represents significant breaking changes.

Next Steps

Additional work will need to be completed. More tests are needed to ensure code coverage, and the remaining API endpoints need to be implemented.

I will continue to do so as time permits

Additionally, a maintainer should look into setting up a Actions pipeline to upload tagged releases to NuGet, as many developers will expect the package to be available in the dotnet ecosystem package library.

[m33p]

Hi @Bottswana I have a question. Why did you choose Newtonsoft over System.Text.Json. The duo_universal_csharp project currently uses System.Text.Json and does not use Newtonsoft. It there something in Newtonsoft that cannot be accomplished with System.Text.Json?

System.Text.Json Positives:

• Its included .NET
• Less memory allocation then Newtonsoft.
• Its faster than Newtonsoft.

https://trevormccubbin.medium.com/net-performance-analysis-newtonsoft-json-vs-system-text-json-in-net-8-34520c21d054

[Bottswana]

Hi @Bottswana I have a question. Why did you choose Newtonsoft over System.Text.Json. The duo_universal_csharp project currently uses System.Text.Json and does not use Newtonsoft. It there something in Newtonsoft that cannot be accomplished with System.Text.Json?

System.Text.Json Positives:

• Its included .NET
• Less memory allocation then Newtonsoft.
• Its faster than Newtonsoft.

https://trevormccubbin.medium.com/net-performance-analysis-newtonsoft-json-vs-system-text-json-in-net-8-34520c21d054

Hi,

I simply have far more experience across all my projects with the battle tested Newtonsoft over the .NET equivalent.
It's also used in many projects and I have a lot more faith in it when writing custom serialisers, which in this case was needed to convert native types to string on the fly for the Duo API.

I would rather focus time on building additional endpoints than changing the JSON library, and while I do not mind if it was something different, I am unlikely to dedicate time to changing it as part of this PR unless someone else wanted to commit the time and test that it is working correctly.