Sunset Chessie and Migrate to FsToolkit.ErrorHandling

[1eyewonder]

Summary

Just some Saturday shenanigans I was playing around with. I was looking over the code and wanted to see what the general thoughts were on migrating the error handling tooling over to FsToolkit.ErrorHandling since it is more "modern/maintained" (IMO). I still have more work to do but figured I'd show the idea off. If we think there is some merit behind it, I would be more than happy to continue on with following through with this work 😄 If we don't see value in it, I can always close it and say it was a good exercise for myself 🤷‍♂️

Note

In addition to error handling changes, I have done some minor List filter/map optimizations to reduce number of iterations in certain areas which I thought were straight forward. I can revert these if we find them to be out of scope.

[smoothdeveloper]

I'm wondering if, for sake of this getting reviewed in detail, there isn't a pro in having a compatibility module under the Chessie namespace.

We would still make sure new code is written with FsToolkit.ErrorHandling, and that code we change conforms to it, but for sake of adjusting the dependency, we would focus on minimizing the diff / having the lowest possible impact on the code.

I'm not familiar with either packages, so unable to assess if compatibility module (Chessie API currently used, implemented in terms of FsToolkit.ErrorHandling) would just work.

Such compatibility module could also be used in other projects that want to take similar migration path.

[baronfel]

This LGTM - replacing a deprecated dependency and aligning with the rest of the ecosystem is a net good.

[voronoipotato]

@baronfel I was rubber ducking for @1eyewonder . We were having challenges getting things to resolve for the integration tests. I'm almost wondering if it would be easier to break it out into two assemblies, one for the netstandard integration tests and the netcore integration tests? This might just be a result of my own ignorance though.