Experiment with longer fuzzing runs for in-process fuzzers

Right now we’re doing 4 consecutive fuzzing runs up to 1hr each. That 1hr includes 10 minutes for corpus merging + some other workload, so we’re actually fuzzing up to 44 minutes (-max_total_time=2650).

Let’s do one 3hr fuzzing run, allocate up to 40 minutes for corpus merging, and the rest for other necessary stuff.

One benefit that we’ve discussed many times is that we’ll be spending less time on reading the corpus on the fuzzer startup.

Another one is to minimize the number of fuzz targets that are timing our during the corpus mergning (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=927447).

If we could add this as a strategy, we would have some way to evaluate the impact, right? //cc @mbarbella-chromium

[inferno-chromium]

Started experiment on OSS-Fuzz. Switched from 4800 (1hr+1200secmerge) to 8400 (2hr+1200secmerge) on July 13 (later in day). Tracking data studio graphs show positive increase on new edges, new features and new units graph. Will let it continue for a day to two, and then try increasing it more.

[inferno-chromium]

Lets wait on the outliers part to be fixed in datastudio graphs, then we can gauge impact correctly!