fix(core/mempool): improve perf of retrieve transactions

[sdbondi]

Description

• improves the performance of transaction retrieval for a block template esp with many inputs
• improves the performance of published block handling with many inputs
• adds execution times for each step later debugging in published block handler
• adds a number of logs with timing

Motivation and Context

Mempool storage has a very long running write lock while retrieving txns (many inputs) for a block and processing a published block. This manifests with the status line freezing and with miners unable to retrieve a block template.

Fairly minor improvements/low hanging fruit, however with many inputs this change greatly reduces the time to complete and I was able to mine these transactions.

Some possible optimisations for future

• re-look at algo for dependent transactions, the way dependent transactions are currently found requires removal and re-insertion of transactions "after the fact" as transactions are retrieved for a block but perhaps should be detected and cached as transactions are inserted to maximise retrieve's perf. Needs more evaluation.
• Evaluate caching the block template, cache is invalidated if a new transaction comes in, a new block is received and reorgs
• if compact inputs are propagated, input.output_hash() will not actually have to generate the hash when doing the O(nmj) comparison. compact input broadcasting from wallets is probably not worth the effort at this stage
• expand the current mempool benchmark suite.

How Has This Been Tested?

Mempool freeze is reduced and blocks can be mined, however it is still slow for many inputs.

[SWvheerden]

LGTM

[hansieodendaal]

I have thoroughly tested this code with coin splits, all good there.

ToDo: Test with spending dust in huge transactions

[hansieodendaal]

I have thoroughly tested this code with spending dust in huge transactions - works perfectly.