Runtime fuzzer

[posvyatokum]

Adding creating of an arbitrary Scenario with Transfer, Stake, and CreateAccount transactions. Also adding fuzzing target.
Currently, all the bounds for random numbers are also chosen randomly (by me).
Next pr will add contract calls, but it will only be for contracts from 'runtime/near-test-contracts'

[bowenwang1996]

Adding a readme on how to run the fuzzer could be helpful

[matklad]

The code looks good to me, left just a couple of small nits.

Two comments/questions:

• should we perhaps add this to the nightly pipeline? To run the fuzzing for half-an-hour every night, or something like this? Not sure what's the best strategy?
• did we try to estimate how well our generator works? Can we, eg, detect an overflow if we replace some of checked_adds with plain +?

[posvyatokum]

• should we perhaps add this to the nightly pipeline? To run the fuzzing for half-an-hour every night, or something like this? Not sure what's the best strategy?
• did we try to estimate how well our generator works? Can we, eg, detect an overflow if we replace some of checked_adds with plain +?

At this point, fuzzer is very weak, so probably shouldn't add it to the nightly pipeline yet.
Currently, I mostly create PR's to approve the basic design. Right after merging this PR, I will create a new one with contract deployment, function calls, and a couple of tricks to make scenarios more realistic. And even then overflows will not be detected in a reasonable time -- these scenarios are too simplistic.
Bowen laid out some examples of what we want to catch #4374 (comment). I will follow these suggestions and hopefully fuzzer will start catching at least intentional bugs quick

[matklad]

At this point, fuzzer is very weak, so probably shouldn't add it to the nightly pipeline yet.

Process-wise, I'd suggest adding stuff to CI as early as possible, and then using CI as a ratchet, to make sure that stuff can progress forward, but can not regress. That is, the benefit of CI at this stage is not that we catch bugs, but that we prevent fuzzing infra itself from regressing.

But this is a "rule of thumb" suggestion, there's little specific benefits in this case.

[bowenwang1996]

At this point, fuzzer is very weak, so probably shouldn't add it to the nightly pipeline yet.

Process-wise, I'd suggest adding stuff to CI as early as possible, and then using CI as a ratchet, to make sure that stuff can progress forward, but can not regress. That is, the benefit of CI at this stage is not that we catch bugs, but that we prevent fuzzing infra itself from regressing.

But this is a "rule of thumb" suggestion, there's little specific benefits in this case.

@matklad do you mind creating an issue for this?