Investigate including precompiles operations as part of simulation testing

[lumtis]

Describe the Issue
Precompiles will become an important component of the protocol and sensitive security wise.

Precompile interaction can involve invariant as mentioned in #2991

We should add precompile interactions as part of the simulation test suite.

Tricky part is that simulation tests are designed for Comsos modules, whereas precompile are smart contract interaction (sending EVM messages), so would potentially involve extending EVM simulation tests

Tasks

Preview Give feedback

1. Add mapping between amount of ZRC20 locked and corresponding cosmos token minted #3312
   SIM_TESTS +1
2. Add new message Deposit ZRC20 in the fungible module #3309
   zetacore +1
   
3. Add new message Withdraw ZRC20 in the fungible module #3310
   zetacore +1
4. Add new message Distribute in the fungible module #3311
   zetacore +1

[kingpinXD]

Precomipiled contracts at a very high high level , bypass the Msg Delivery System that Cosmos has . We can think of the a precompiled contracts similar to applying state changes directly based on user input [ it would similar to if we import the keeper into the x/module/cli package ]

Every contract call consists the following steps

1. Function router , to figure out what the call is going to do
   https://github.com/zeta-chain/zeta-node/blob/7504de4ae8711daab30b72a38743b8687343485b/precompiles/staking/staking.go#L139-L139

2. Logic to fetch the arguments [ Similar to CLI in cosmos ]
   https://github.com/zeta-chain/zeta-node/blob/7504de4ae8711daab30b72a38743b8687343485b/precompiles/bank/method_deposit.go#L34-L60

3. State transtions [Similar to DeliverTX in cosmos]
   https://github.com/zeta-chain/zeta-node/blob/7504de4ae8711daab30b72a38743b8687343485b/precompiles/bank/method_deposit.go#L62-L110

With simulation tests we primary want to test , the step 3.
Since the simulation testing setup for cosmos supports delivery of MSG's only , and not arbitrary state changes , it would make sense to have step 3 encapsulated as a cosmos MSG . This would additionaly provide us a option to expose this message via a GRPC or CLI call on cosmos sdk if needed in the future

We already see a similar pattern being followed the the staking precompiles where , we are internally calling a Comsos Message from the procompile , and since the MSG is already being tests via simulation tests , it provides us the coverage needed
https://github.com/zeta-chain/zeta-node/blob/7504de4ae8711daab30b72a38743b8687343485b/precompiles/staking/method_unstake.go#L58-L65
https://github.com/zeta-chain/zeta-node/blob/7504de4ae8711daab30b72a38743b8687343485b/precompiles/staking/method_move_stake.go#L65-L73

This same pattern can be easily extended to Bank and distribution precompiles .

[kingpinXD]

Attaching a flow digrad for what the testing coverage would look like following this pattern. It uses Bank Deposit as an example , but can be used for an contract call

[kingpinXD]

Replying to the message here as it more appropriate to continue this converstation on the parent issue
#3309 (comment)

I agree witht he points mentioned , However I would want to note a few things before we close off the three tasks entirely .

• The new Msgs mentioned do not add any new logic but in fact , just extract the exisitng logic into a function to make it more testable . This seems to a common coding practice to enable better test coverage . Even if we dont add the message the same logic can be executed , but not tested .
  The problem here being as you stated it add an additional maintanace headache of a Message . Imo if the extra effort might be worth it .

• The similar pattern of encapsulating a cosmos message by a precompile action is allready being followed for staking functions . Additionaly this allows us use the same functionalty on the cosmos side as well (If thats desired at all )

• Alternatively , we can try to emulate arbitrary state changes in the simulation test directly ( Which should be posible , but since there would not be msg delivery , the stats such as , passed / failed etc would not be available ).