pallet-revive: add interface to implement mocks and pranks

[alexggh]

Needed for: paritytech/foundry-polkadot#334.

In foundry-polkadot we need the ability to be able to manipulate the msg.sender and the tx.origin that a solidity contract sees cheatcode documentation, plus the ability to mock calls and functions.

Currently all create/call methods use the bare_instantiate/bare_call to run things in pallet-revive, the caller then normally gets set automatically, based on what is the call stack, but for forge test we need to be able to manipulate, so that we can set it to custom values.

Additionally, for delegate_call, bare_call is used, so there is no way to specify we are dealing with a delegate call, so the call is not working correcly.

For both this paths, we need a way to inject this information into the execution environment, hence I added an optional hooks interface that we implement from foundry cheatcodes for prank and mock functionality.

TODO

• Add tests to make sure the hooks functionality does not regress.

[alexggh]

@athei @smiasojed changed a bit the approach instead of injecting data I added a mocks hooks trait that we then implement in foundry codebase here: https://github.com/paritytech/foundry-polkadot/pull/334/files#diff-9e3b7cd881b3ef657db58bf38a66549a3b651f550caa7d623f8d4b20a813ea79R73, let me know what you think.

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/18350472696
Failed job name: test-linux-stable-no-try-runtime

[athei]

Where is that used from outside the crate?

[alexggh]

Here it was already used: https://github.com/paritytech/foundry-polkadot/blob/9267395a9d2a822bd4d76b9e47e91ee44eb9e4ae/crates/revive-strategy/src/tracing/mod.rs#L22.

[smiasojed]

Should Self::transfer_from_origin be called from the fn run when we are mocking the call?

[smiasojed]

Should we charge deposit / gas if the call is mocked

[alexggh]

Should Self::transfer_from_origin be called from the fn run when we are mocking the call?
Should we charge deposit / gas if the call is mocked

Good points will have to look in to it, the existing mock/prank testsuite seems to be working well, so probably we are doing the right thing here.

[alexggh]

Should we charge deposit / gas if the call is mocked

Looked a bit in foundry and it seems that mocked calls don't consume any gas, https://github.com/paritytech/foundry-polkadot/blob/9dd622a57199cbce23603874bda1d656b5b6e3ec/crates/cheatcodes/src/inspector.rs#L1039, so I guess we need to make it the same here.

[alexggh]

Should we charge deposit / gas if the call is mocked

Looked a bit in foundry and it seems that mocked calls don't consume any gas, https://github.com/paritytech/foundry-polkadot/blob/9dd622a57199cbce23603874bda1d656b5b6e3ec/crates/cheatcodes/src/inspector.rs#L1039, so I guess we need to make it the same here.

Did some digging a bit and this PR is actually doing the right thingm because we don't actually execute the contract and we just use the mocked values, no gas and storage deposit is recorded in the frame, so we don't charge anything for mocked calls and that is the exact same behaviour as mainline foundry.

[smiasojed]

Should Self::transfer_from_origin be called from the fn run when we are mocking the call?
Should we charge deposit / gas if the call is mocked

Good points will have to look in to it, the existing mock/prank testsuite seems to be working well, so probably we are doing the right thing here.

I think that transfer will happen when:

1. External call to contract (EOA → Contract)
2. Contract calling another contract (Contract A → Contract B)
3. Contract instantiation (Deploy with value)

Transfer will NOT happen when:

1. EOA→EOA (plain account to plain account)
2. EOA→non-existent address

Is it intentional?

[alexggh]

Should Self::transfer_from_origin be called from the fn run when we are mocking the call?
Should we charge deposit / gas if the call is mocked

Good points will have to look in to it, the existing mock/prank testsuite seems to be working well, so probably we are doing the right thing here.

I think that transfer will happen when:

1. External call to contract (EOA → Contract)
2. Contract calling another contract (Contract A → Contract B)
3. Contract instantiation (Deploy with value)

Transfer will NOT happen when:

1. EOA→EOA (plain account to plain account)
2. EOA→non-existent address

Is it intentional?

Alright, I see your point, I did some investigations and foundry mainline doesn't do any transfer of value when calls are mocked, so I will make that consistent for our implementation as well.

[alexggh]

/cmd prdoc --audience node_dev --bump minor

[smiasojed]

LGTM, thanks