feat(evm): add shrinking to invariant testing

[joshieDo]

Motivation

Traces from invariant failures can really be long. Especially with a high invariant_depth value. This aims to reduce the sequence to its minimum representation.

Solution

Add some basic shrinking:

/// Tries to shrink the failure case to its smallest sequence of calls.
///
/// Sets an anchor at the beginning (index=0) and tries to remove all other calls one by one,
/// until it reaches the last one. The elements which were removed and lead to a failure are
/// kept in the removal list. The removed ones that didn't lead to a failure are inserted
/// back into the sequence.
///
/// Once it reaches the end, it increments the anchor, resets the removal list and starts the
/// same process again.
///
/// Returns the smallest sequence found.

Is there a need for it to be optional?

[mattsse]

sounds reasonable,
wdyt @onbjerg?

[gakonst]

should we add a unit test which ensures that the number of calls actually is shrinked?

[gakonst]

Nit - can pull this outside of the loop and return false early, before iterating?

[joshieDo]

Slightly modified it, but the goal here is to check that the invariant has, in fact, been broken after a call.

So pulling this outside of the loop is not what we want

[gakonst]

nit: you don't need to collect here given you'll iterate over this immutably again in fails_successfully

[onbjerg]

the calls for invariant tests should be a proptest ValueTree/Strategy. the shrinking logic is in ValueTree::complicate (more calls?) and ValueTree::simplify. i think looking at how the value trees for a Vec<T> works would suffice. generally this looks ok but I'd prefer we use the "standard" approaches if possible so it's easier to migrate later/maintain as opposed to it being a totally separate thing

proptest will already rerun the failing case and call complicate/simplify to try and shrink the example, so a lot of this logic essentially duplicates that behavior

[joshieDo]

We are currently using proptest only for strategy/value generation on invariant tests.

Might be my inexperience with the library, but at the time of the invariant implementation I hit some limitations, which lead me to go around its standard use.

Example, for a run of depth 15, I want to be able to generate 15 values lazily (as we fill the dictionary with more in-context values), instead of getting all 15 values straightaway. Which would disregard any newly generated contracts, for example. Context:

foundry/evm/src/fuzz/invariant/executor.rs

Lines 107 to 110 in fb9bc90

	// The strategy only comes with the first `input`. We fill the rest of the `inputs`
	// until the desired `depth` so we can use the evolving fuzz dictionary
	// during the run. We need another proptest runner to query for random
	// values.

from inside test_runner.run(| | {

foundry/evm/src/fuzz/invariant/executor.rs

Lines 185 to 193 in fb9bc90

	// Generates the next call from the run using the recently updated
	// dictionary.
	inputs.extend(
	strat
	.new_tree(&mut branch_runner.borrow_mut())
	.map_err(|_| TestCaseError::Fail("Could not generate case".into()))?
	.current(),
	);
	}

This however, made it impossible to use the shrink functionality, since proptest will try to shrink with only the first generated input. That's why there's a line with .no_shrink() somewhere.

[onbjerg]

@joshieDo That's not entirely correct - proptest entirely discards the ValueTree on every test case, so the "first generated value" will be unique every time the closure we give proptest is run. In other words, the "first generated value" is in the context of a single test case (1 run), not the entire test (256 runs). All of the logic around ValueTree's are only really run whenever a test case fails to try and shrink it

[onbjerg]

Talked async w @joshieDo, I don't have enough of an overview of how the primary strategy works for us to meaningfully progress on possibly using proptest for the shrinking, so you can ignore my comments on the PR - we can look at it later