core/txpool, miner: speed up blob pool pending retrievals

[karalabe]

This PR adds a benchmark to the blobpool to measure the execution speed of pending transaction retrieval. Note, the benchmark uses an in-memory bill of 10GB and needs to pre-generate 80K private keys. It takes 5 minutes.

Based on the benchmark, the PR also contains some fixes to the pending retrieval:

• Preallocations of the pending map and individual slices shaved off 10-15%
• Replacing the time.Now loop invocation with an outer one resulted in an additional 10-15%
• Avoiding the uint256 to bigInt conversion shaved off an additional 50%

Due to the last one, the PR changes this all over the place. This does mean that the legacy pool starts to pay the price in exchange. That said, the legacy pool is capped to about 4K txs, whereas the blobpool currently 80K, so it's worth it. Also, ideally the legacy pool would also start using uint256 and should be resolved like that.

[holiman]

The previous PR made Pending take a basefee/blobfee. This opens up for further optimizations.
After a the pending is delivered to the miner, we do

		txs := newTransactionsByPriceAndNonce(env.signer, remoteTxs, baseFee)
		if err := w.commitTransactions(env, txs, interrupt, tip); err != nil {

In this method, we iterate them all once more, and wrap it as newTxWithMinerFee

func newTransactionsByPriceAndNonce(signer types.Signer, txs map[common.Address][]*txpool.LazyTransaction, baseFee *uint256.Int) *transactionsByPriceAndNonce {
	// Initialize a price and received time based heap with the head transactions
	heads := make(txByPriceAndTime, 0, len(txs))
	for from, accTxs := range txs {
		wrapped, err := newTxWithMinerFee(accTxs[0], from, baseFee)

We also split it up

• heads: the first transaction for each account
• txs the following transactions for each account

We also do a heap.Init(&heads), so we can pop from the immediately applicable transactions at any time. These operations on pending had to be deferrred until this point, because the pools were not fee-aware, they just delivered the pending map and done.

Now, however, they are fee-aware, so why not make them return something like this

// pendingSet represents a set of pending transactions, delivered by a subpool.
type pendingSet{
	heads 	[]*LazyTransaction // Next transaction for each unique account (price heap)
	txs map[common.Address][]*LazyTransaction// Per account nonce-sorted list of transactions
}

We could even push it a bit further, so that heads is not []*LazyTransaction, but a proper []*txWithMinerFee. This will

• Save us another round of iterating everything O(n),
• Save us the memory-intensive wrapping of every head-transaction into yet another type, and corresponding list-shortening in txs[from] = accTxs[1:]
• We can also get rid of the fields GasFeeCap and GasTipCap from LazyTransaction, if we replace them by a field Fees.

One final thought, not sure it's worth it:

• The pendingSet could contain the reference to the pool/resolver, so we can remove that field from LazyTransaction might

And, as we've already discussed, having a pendingSuperSet which keeps the subpools pending sets disjoint makes it easy to "unplug" the blob-tx-set once the blobspace is full.

[holiman]

LGTM