GeneralizationStage takes an unreasonably long time

[addisoncrump]

While testing GeneralizationStage in libafl_libfuzzer, we observed that some inputs may take exceedingly long amounts of time to be generalized. This is due to two issues:

• GeneralizationStage cannot recover if a solution causes a crash or timeout, meaning that the fuzzer may never be able to complete a stage tuple execution for an input which has this behaviour (related: Refactor stages to allow for continuation after crashes #1341)
• GeneralizationStage attempts to execute the input between every gap discovered in the input for whether it removes the most-recently-novel edges. This can mean tens of thousands of executions spent on generalization, only to squeeze out a few more inputs that might trigger new edges.

We should investigate if we can improve its performance or switch to other strategies (see: #1542).

[s1341]

I can confirm that this is still an issue!

[tokatoka]

there's no real solution to this problem

[domenukk]

Can't we simply do a timeout and if it takes too long, skip it?

[tokatoka]

not a time out but i already have the upper bound on how many times it does this stage
but it's not a solution

[domenukk]

Why is a timeout not a solution, it keeps it from getting locked up

[tokatoka]

longer inputs will have timeout. so by having a timeout you can't do this stage properly with long inputs