core/txpool: remove queue, implement temporary buffer (limbo)

[holiman]

This PR implements the "Limbo" idea.

---

"Future" transactions are problematic, in that it can be used to push pending transactions out. The reason for even having future transactions is that we cannot guarantee stable delivery: a node has [tx1, tx2], and announces it to a peer. During delivery, the peer may receive them in the order [tx2, tx1], and not necessarily within the same network packet/batch. When this occurs, it would be bad UX if we dropped tx2.

To mitigate this, what we can do is have a 'limbo'. A transaction entering the node can take two paths:

1. fast-path: this tx is executable, and can thus enter the
2. slow-path: this tx is not executable, and is put into 'limbo'.

Every N seconds, we

1. Sort transactions in limbo by nonce.
2. For each transaction
   • If is executable, add to pool,
   • Else: discard

At the end of this loop, the limbo is empty again

In this system, the transaction pool itself is only ever aware of executable transactions. A user submitting multiple transactions may notice a degradation in propagation speeds of the "later" transactions, but should not experience them being dropped by the network.

---

This PR is a work in progress, which implements most of this. The removal of the queue makes a lot of code redundant. For now, I have chosen to leave the code mostly in place, but commenting it out. This is to make it easier for a reviewer to check and see that the removed code indeed was not useful any more.

I also split up the validation in two phases:

• "generic" or "basic" validation, which is more or less static. Is the transaction essentially valid?
• "stateful" validation, which is more temporal: is the transaction valid at this time? This check is stateful, and needs to be re-performed from time to time.

---

A lot more work needs to be done on the PR itself, and also the tests are failing en masse.

[MariusVanDerWijden]

One idea would be to evict the transactions from limbo based on their arrival time. I believe we have that in the transaction object somewhere. This would provide a total ordering of the limbo and prevent us from evicting transactions that just arrived before we do the reorganize procedure

[holiman]

I'll close this for now, might pick it up at a later point in time.