Enhance Mempool performance

[tiram88]

This PR addresses the issue of the mempool being a bottleneck in the first testnet-11 experiment @ 10 BPS.

The previous monolithical design did lock both the Mempool and to some extent the virtual processor during every call to its public functions, through the Manager that owns it, leading to some long delays. The new general design is to split the functions into simpler atomic steps logically protected by a lock on the mempool when the latter is implied. This approach has following consequences:

• The Manager owning the Mempool instance no longer is a simple pass-through locking and exposing mempool functions publicly. An important part of the mempool logic gets moved into the manager.
• Some verification steps must sometimes be duplicated, particularly checking for double spends, since executing a Manager function is no longer atomic.
• Some processes are reorganized and some behaviors do change, taking advantage of the potential this new design offers.

Another performance improvements are brought:

• Processing batches of transaction in a topological order, forming sub-batches by levels of chained dependency
• Parallel validation of sub-batches of transactions into the virtual processor, processing those in chunks formed up to a maximal mass so the virtual processor does lock for too long,
• A more efficient algorithm for making room in the mempool when it is full and some transaction must be added. This process also has a modified behavior: the transaction with the lowest fee rate is removed, but (this is new) only among transactions having no chained dependency and not being a parent of the transaction getting added.

Validate and insert a single transaction

In order to bring a much finer lock granularity the function of validating and inserting a transaction into the mempool is split in 4 steps:

1. pre-validation (read lock on Mempool)
2. validation by the virtual processor (no lock on Mempool)
3. post-validation and insertion (write lock on Mempool)
4. validation and insertion of unorphaned transactions (see below)

Validate and insert unorphaned transactions

Following any insert of a transaction into the mempool, some orphan transactions may be unorphaned. Here again we take advantage of the new design. On insertions, room is made on the fly if necessary and then we keep looping as long as new transactions are unorphaned (both new behaviors).

1. parallel validation of batches of transactions (no lock)
2. post-validation and insertion (write lock)
3. in case of new unorphaned transactions, loop to step 1 (new behavior)

Validate and insert transactions in batch

This function is involved in the transaction relay flow, where a bunch of transactions gets broadcasted to peers. The batch is processed in a topological order by level of chained dependency (new behavior). For each level:

1. pre-validation (read lock)
2. parallel validation of the sub-batch of transactions by the virtual processor (no lock)
3. post-validation and insertion (write lock)
4. validation and insertion of unorphaned transactions

Handle the transactions of a block newly added to the DAG

Here again, a split in 3 steps adds granularity in the locks.

1. handling of transactions (write lock),
2. validation and insertion of unorphaned transactions
3. expiring the low level transactions (write lock)

Revalidate high priority transactions

This is probably the most important bottleneck alleviation, together with tx relay broadcasting. This process occurs only every 30 seconds and for a node getting a very high rate of local transactions, it was implying a very computer intensive processing all under a single atomic lock of the mempool.

This gets redesigned as:

1. getting all the high priority transactions (read lock)
2. processing the batch in a topological order by level of chained dependency, instead of a "standard" Kahn's in-degree algorithm (new behavior)
3. populating all transactions with UTXO entries found in the mempool (read lock)
4. parallel validation of the sub-batch of transactions by the virtual processor (no lock)
5. updating the transactions in the mempool and removing the invalid ones, along with all their redeemers (write lock)

Since the process is now much more granular in how it locks both the mempool and the consensus, it may happen that some high priority transactions present at the beginning got removed (mined in a block, invalidated, etc.) during the (relatively long) process. The transaction id may or may not be returned as accepted depending on the sequence of events. But no impact is expected on the node. It will simply try to rebroadcast a transaction id that is no longer present and the peers requesting it will eventually get a TransactionNotFound, which may and does occur anyway for other reasons.

The behavior changes compared to the golang version in that on transaction validation error the error is simply logged and the execution continues whereas in golang the execution halts returning the error.

Performance gains

Cautious note: an upcoming PR will add a benchmarking infrastructure making it possible to measure the gains in performance, hence revealing to which extent this new design actually alleviates the bottleneck issue.

Depending on the measures, some further adjustments might be needed.