SORU: EVM: executable to chunk transaction for the kernel

Context

To fit large transactions into the inbox, the evm proxy chunks them into manageable pieces, that the kernel can assemble.

This extract this functionality into an executable that takes a rollup address (sr1... format) and a raw ethereum transaction (hex encoded, without the 0x). If no address is provided, the address 0 is used.

Manually testing the MR

Proxy still works:

dune exec tezt/tests/main.exe --  --file evm_rollup.ml

Chunk something:

dune exec src/bin_evm_proxy/tx_chunker/octez_smart_rollup_wasm_chunker.exe "sr1SKEeoKZizGDczpS8JgYiAdkjyN8Am6TcK" "0xf901f2808506fc23ac00831000008080b9019f608060405234801561001057600080fd5b5061017f806100206000396000f3fe608060405234801561001057600080fd5b50600436106100415760003560e01c80634e70b1dc1461004657806360fe47b1146100645780636d4ce63c14610080575b600080fd5b61004e61009e565b60405161005b91906100d0565b60405180910390f35b61007e6004803603810190610079919061011c565b6100a4565b005b6100886100ae565b60405161009591906100d0565b60405180910390f35b60005481565b8060008190555050565b60008054905090565b6000819050919050565b6100ca816100b7565b82525050565b60006020820190506100e560008301846100c1565b92915050565b600080fd5b6100f9816100b7565b811461010457600080fd5b50565b600081359050610116816100f0565b92915050565b600060208284031215610132576101316100eb565b5b600061014084828501610107565b9150509291505056fea2646970667358221220ec57e49a647342208a1f5c9b1f2049bf1a27f02e19940819f38929bf67670a5964736f6c6343000812003325a0e0d5dd3ddec07eb85eb066c7782ab64a4f9f47f22e444c147708d3277dba6d68a03e358c75e5c2436ada1dcebe4aa1391797658950a9a5abae90ccff61ce5e7f34"

Should return a transaction that can be read by the kernel

de63f187d952bc04a17c07956624e1520f7fd4a3004b288d96bde6bd3a17f420f129abc7f0ca48f1e5149b562ec6c6023c9358d463f901f2808506fc23ac00831000008080b9019f608060405234801561001057600080fd5b5061017f806100206000396000f3fe608060405234801561001057600080fd5b50600436106100415760003560e01c80634e70b1dc1461004657806360fe47b1146100645780636d4ce63c14610080575b600080fd5b61004e61009e565b60405161005b91906100d0565b60405180910390f35b61007e6004803603810190610079919061011c565b6100a4565b005b6100886100ae565b60405161009591906100d0565b60405180910390f35b60005481565b8060008190555050565b60008054905090565b6000819050919050565b6100ca816100b7565b82525050565b60006020820190506100e560008301846100c1565b92915050565b600080fd5b6100f9816100b7565b811461010457600080fd5b50565b600081359050610116816100f0565b92915050565b600060208284031215610132576101316100eb565b5b600061014084828501610107565b9150509291505056fea2646970667358221220ec57e49a647342208a1f5c9b1f2049bf1a27f02e19940819f38929bf67670a5964736f6c6343000812003325a0e0d5dd3ddec07eb85eb066c7782ab64a4f9f47f22e444c147708d3277dba6d68a03e358c75e5c2436ada1dcebe4aa1391797658950a9a5abae90ccff61ce5e7f34

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR