🗞️ Allow expected reverts in verifyAndExecutePackets and fix forge coverage in TestHelper

[DanL0]

• adds support for two vm.expectRevert signatures (bytes4 and bytes memory)
• renames verifyPackets to verifyAndExecutePackets for clarity
• adds tests to "@layerzerolabs/test-devtools-evm-foundry"
• use structs in TestHelper to make forge coverage working, fixes: forge coverage fails to run on OApp LayerZero-v2#42 (related PR: use structs in testhelper to reduce stack size LayerZero-v2#92)

Depends on:

• Move Foundry TestHelper variables to storage to fix forge coverage #791

[St0rmBr3w]

Should we add a revert argument for checking the composed delivery?

[TRileySchwarz]

This is also missing fixing the tests, or perhaps this is just PoC for now

[DanL0]

seems vm.expectRevert Foundry doesn't behave like it's documented in Vm.sol, related issue: foundry-rs/foundry#7629

Reported to Foundry team

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub ↗︎

👍 No dependency changes detected in pull request

[TRileySchwarz]

I dont know if I really agree on imbedding the expected revert data into the function like this, is there a functional reason why we dont just rely on the bubbled up revert and catch it with the vm.expectRevert inside of the test files implementation of this contract?

Otherwise it's unconventional compared to how you traditionally would read a testfile using vm.

[DanL0]

We could probably do that if we expose more granular functions from the TestHelper, eg. split verification and execution of packets. Right now vm.expectRevert only allows to catch revert in next function call or something and it doesnt catch reverts properly

[ryandgoulding]

Agreed with @DanL0 , you can't just expectRevert() to be a catch-all for verifyPackets()

[TRileySchwarz]

We should split this PR into seperate smaller ones:

One for refactoring the endpoint setup to be more verbose. Excluding the "executeAndVerify" portion

[DanL0]

We should split this PR into seperate smaller ones:

One for refactoring the endpoint setup to be more verbose. Excluding the "executeAndVerify" portion

#791