blockmanager: Invert transaction handling during reorgs

[sefbkn]

The order that new transactions are added to the mainpool and included in block templates currently follow a topological ordering. Additionally, during a disapproval event or reorg, not-new transactions are added back to the mempool in FIFO order from the perspective of the block containing those transactions. The current behavior introduces complexity for algorithms whose view is limited to adjacent transactions at a point in time.
Instead, transactions added to the mempool that are sourced from a block should be added in reverse topological order (LIFO). This would simplify code that operates on unconfirmed transaction chains (such as CPFP) by ensuring that there are no "gaps" between related transactions already in the mempool and transactions added back to the mempool at any point during a reorg.

In other words, if a chain of dependent transactions is included in a block template in the order (A, B, C, D), then during a reorg or disapproval event those transaction should be added back to the mempool in the opposite order (D, C, B, A).

[davecgh]

Agreed that it makes more sense to do it this way, even without the newer selection logic because transactions that are later in the regular transaction tree can always spend from those earlier in the tree. This logic is already implemented when updating the UTXOs during block disconnection because it's required to maintain a correct view.

That said, I suspect what would would be an even better in general if time is going to spent in this area anyway is to create a batching mechanism instead.

I would expect that all transactions being undone in a reorganization due to blocks disconnecting could be added to an ordered queue (in reverse order, as noted) and then removed from the queue as blocks are reconnected in the reorg. What is left once the reorg is done could then be applied to make the mempool consistent, as opposed to updating it for every block step by step along the way.

[sefbkn]

Picking this one up.

[davecgh]

Resolved by #2956.