Do not sync initial corpus, or don't do it too fast

[andreafioraldi]

From somebody using LibAFL:

I'm hitting this panic from time to time: https://github.com/AFLplusplus/LibAFL/blob/main/libafl_bolts/src/llmp.rs#L1114
I think it's because I'm launching a lot of clients, that may be slow, with a big corpus.
the constant definition says:

/// The max number of pages a [`client`] may have mapped that were not yet read by the [`broker`]
/// Usually, this value should not exceed `1`, else the broker cannot keep up with the amount of incoming messages.
/// Instead of increasing this value, you may consider sending new messages at a lower rate, else your Sender will eventually `OOM`.
const LLMP_CFG_MAX_PENDING_UNREAD_PAGES: usize = 3;

My answer to have this thing fixed quickly is this one:

a quick and dirty patch is this one https://github.com/AFLplusplus/LibAFL/blob/main/libafl/src/state/mod.rs#L751
change the call to evaluate_input to evaluate_input_events that takes a parameter more, send_events, set it to false

How should we address this problem? Apply my patch? We can assume all the nodes load the initial corpus by themself so no need to create NewTestcase events, but maybe there are situation I'm not thinking about now that are useful.
The initial corpus loading methods are already very configurable and we have many variants, I would avoid adding another one to let the user choose whatever send NewTestcase messages when loading the initial corpus or not and simply hardcode the best solution.

[tokatoka]

does increasing LLMP_CFG_MAX_PENDING_UNREAD_PAGES fix the problem?

[andreafioraldi]

It may as workaround, but with more cores and more files in the initial corpus it will reappear IMO

[domenukk]

We have multicore loading of testcases (which is what ppl should use).
I think the best solution is to have a min time between messages sent. I think we implemented that at some point?