kaiax/gasless: Implement worker for tx bundle

[Mdaiki0730]

Proposed changes

Merging this PR will enable worker bundling in kip-245.
New features about kip-245

• Bundle Generation Logic
• Bundle Execution (commitBundleTransaction)
• Bundle Rollback
• Delaying Timeout

Also, some changes were made to implement above.

• The transactions that the worker iterates when ApplyTransactions has been changed from txs(TransactionsByPriceAndNonce) to incorporatedTxs([]interface{}).
  • For this we have added new methods to task, which mirror Pop and Shift from TransactionsByPriceAndNonce.
• Define the methods in the builderModule as public functions.
  • These do not use any struct fields so functions are sufficient.
• Now that we have the RegisterTxBundlingModule, a node can use it to register the TxBundlingModule.

About Pop and Shift
We create a dependency graph during pop for the following reasons.

Shift just advances to the next tx, while pop deletes all tx that have the same sender as the failed tx.
This deletion may affect other bundles in the following cases:

txs =     [ G1 A.T1 B.T1 A.T2 B.T2 C.T1 ]
bundle =  [ G1 A.T1 ]
bundle2 = [ B.T1 A.T2 ]
bundle3 = [ B.T2 C.T1 ]
on A.T1 revert, pop(txs, 2) => txs = [ ]

[ G1 A.T1 B.T1 A.T2 B.T2 C.T1 ]
pop 2 elements
[ B.T1 A.T2 B.T2 C.T1 ]
A.T2 is broken (nonce) so remove it
[ B.T1 B.T2 C.T1 ]
bundle2 is broken so remove B.T1
[ B.T2 C.T1 ]
B.T2 is broken (nonce) so remove it
[ C.T1 ]
bundle3 is broken so remove C.T1
[ ]

Create TestScenario

1. Transfer (reservoir1 -> anon) using a legacy transaction four times.
   Create a mock TxBundlingModule and create a bundle for each two tx.
   At that point, tx4 fails with nonceTooHigh and tx3 is reverted.
2. Transfer (reservoir2 -> anon) using a legacy transaction two times.

There were also some test util changes.

• Add the ability to assign TxBundlingModules and BuilderModules to MineABlock.
• Add txHashesExpectedFail to accountMap Update
  • To support tests that assume tx failure

Types of changes

Please put an x in the boxes related to your change.

• Bugfix
• New feature or enhancement
• Others

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING GUIDELINES doc
• I have read the CLA and signed by comment I have read the CLA Document and I hereby sign the CLA in first time contribute
• Lint and unit tests pass locally with my changes ($ make test)
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Related issues

• Please leave the issue numbers or links related to this PR here.

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[Mdaiki0730]

I rebased feat/gasless to include #263. I force pushed and there are no conflicts.
Due to the change made by 768fcea, he TxBundlingModule is now registered to the Miner during cn init.

[ian0371]

In terms of timeout test, temporarily setting timeout to 150us depends on PC spec, so timeout can occur (1) before executing any txs, (2) during tx execution, (3) after all tx execution. In case of (1), the test can fail. In case of (3), the test will be successful but timeout wouldn't have occurred. Later let's improve accuracy of timeout test so timeout almost always occurs at (2).

     (1)                   (2)                    (3)
|------------|-------------------------------|-------------|
             V                               V
    bundle execution start         bundle execution end