Add fuzz tests about parsec

[ionut-arm]

A first part of the "dreamed-up" fuzz tests was merged with #97 - others will be added at some point

[ionut-arm]

The AFL crate is not really all that good - lack of documentation and functionality.
Started using libfuzzer instead, which seems to have better support and tooling. Not that thoroughly documented, but good overall, quite easy to set up.

There was an idea to try and get the project into OSS-Fuzz, but projects accepted there need to have a large user base (or be critical to IT infrastructure). So... maybe a task for the future :)

[hug-dev]

Dealt with in #94

[ionut-arm]

I've realized that the way we're doing testing is too "sparse" - we're testing the system as if a client was using it - essentially more like a stress test than a fuzz test. This means that a lot of the packets would be lost along the way and never reach the providers.
My new idea is to crack open the service and extract the parts that we deem more complex and inherently prone to crashes/bugs etc. The main "pipeline", i.e. the frontend handler, dispatcher and backend handler are relatively small pieces of code that can be audited by hand/eye (if we don't consider all the parsing and conversions as part of that).
Hence, I'll attempt to describe a number of tests and label them in an enum (along with their inputs). Tests would be something more specific than before - create a key using provider P - but still have the full freedom over the inputs to the operation. The fuzzer will generate a variant of the enum at each run and hence all the tests will be run "at once".
The main areas that I'll focus on are the two boundaries - the providers and the service interface.

[hug-dev]

I think that it might be indeed more efficient to fuzz test only specific components.
But there is still, to me, to do a fuzz test on the whole service (fuzzing the stream sent to the FrontEndHandler). Those things could happen in parallel!

[ionut-arm]

Indeed, it's probably a good idea to have both. I'll keep them as separate fuzz targets, fuzz_service and fuzz_components. Might add them in separate PRs, since the fuzz_service part is almost done.

[ionut-arm]

And I do believe it's a really good idea to fuzz the FrontEndHandler instead of bypassing it and going straight to the Dispatcher!

[hug-dev]

Should we maybe close this for the release and add a new issue for the other fuzz targets? Or should the other targets also be part of Parsec for production readyness?

[ionut-arm]

Unsure, it all depends on how much time we have until a release is imminent. Let's close, I'll open another one and not assign that one to Parsec 1