kaiax/builder: set timeout for bundle tx

[ulbqb]

Proposed changes

This PR solves the dangling transaction problem.

Problem

Nodes have kept to hold potentially failed bundle transactions in the pending because they don't have any way to know if they succeed or fail and nodes haven't remove any transactions without results. Usually, nodes can know tx result through propagated created blocks but the results of the transactions in failed bundle aren't in any blocks.

Solution

• PendingTimeout - All nodes remove the builder module transactions from the pending in certain period. Timeout is 10s.
• KnownTxTimeout - All nodes reject the builder module transactions for certain period after they are received. Timeout is 30s.

How it works

The below image shows how a tx is propagated and is removed from pending if tx is failed bundle tx against before and after this pr.

[as-is]

time\pending	EN0	EN1	PN0	PN1	CN0	CN1	desc
0s	tx						EN0 receives bundle tx.
0.5s	tx	tx	tx	tx	tx	tx	tx is propagated.
1s	tx	tx	tx	tx		tx	CN0 is proposer and tx fail.
1.5s	tx	tx	tx	tx	tx	tx	tx is propagated.
2s	tx	tx	tx	tx	tx		CN1 is proposer and tx fail.
...	tx	tx	tx	tx		tx	loop

[to-be]

time\pending	EN0	EN1	PN0	PN1	C01	CN1	desc
0s	tx						EN0 receives bundle tx.
0.5s	tx	tx	tx	tx	tx	tx	tx is propagated.
1s	tx	tx	tx	tx		tx	CN0 is proposer and tx fail.
1.5s	tx	tx	tx	tx		tx	tx is propagated but rejected by knownTxTimeout.
2s	tx	tx	tx	tx			CN1 is proposer and tx fail.
7s	tx	tx	tx	tx			tx is propagated but rejected by knownTxTimeout.
10s							tx is marked with unexecutable by pendingTimeout and will be removed.
20s							tx is rejected by knownTxTime even if tx is left in network.
40s	tx						nodes can get to receive the same bundle tx after knownTxTimeout.

(PS I had AI create most of the test. That's awesome😎)

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...

[hyeonLewis]

Just a quick thought: The EN and PN don't include module tx in txpool but only broadcast them. So after broadcasting tx, no EN and PN has module tx, but only CN will have it. (CN only broadcasts tx to CNs)

It'll have side effects by not storing tx in txpool (Tx might be missing before reaching to CNs)

[Mdaiki0730]

If one tx is a module tx, is there a need to have a builder module?
https://github.com/kaiachain/kaia/pull/309/files#diff-1372f977fe5a5f233ec6a55693c89acccaac3244936d3896a51b1dba6ace8757R33
I misunderstood, please don't care.

[ulbqb]

I changed pending timeout (30s to 10s) and known tx timeout (60s to 30s) for optimization.