NRD rules and "recent" kernel pos index

[antiochp]

The new NRD kernel variant was introduced in #3303.

This PR adds the kernel_pos index to track "recent" NRD kernel history for efficient validation of the NRD relative lock height rule.

---

LMDB index impl

• add linked list implementation (lmdb based)
• add kernel_pos index based on linked list implementation
  • push latest kernel pos to head of list
  • peek latest kernel pos
  • pop latest kernel to support rewind

---

NRD rule validation

• apply_block (during block processing pipeline):
  • push NRD kernels to index
  • validate NRD relative lock height rule
  • test coverage for NRD rule validation
  • ensure rewind of kernel_pos index when rewinding blocks
• rewind kernel_pos index when rewinding "single block" during block processing
  • test coverage of rewind scenario
• validate NRD relative lock heights when processing transactions in stempool/txpool
  • test coverage for NRD rule validation

---

Txpool

• pool tests currently "mock" out the chain impl which complicates testing of NRD rules (see Rework pool tests to use real chain (was mock chain) #3342)
• pool currently identifies txs based on kernel (and kernel hash) and this does not play nicely with NRD kernel reuse (ok for now but should be revisited)

---

Rebuild Index

• rebuild kernel_pos index on fast sync
• rebuild kernel_pos index on node init

---

Fast Sync

• validate NRD kernels across full historic kernel set

[tromp]

in what cases would we call process_block_single without having validated/processed the header already?
(I would naively expect never)
Does header validation not commit it to db?

[antiochp]

In most cases we will have processed "header first".
The first broadcast hop from a miner after mining a new block is done as a "full block" and skips the "header first" propagation as we know nobody has seen this block yet.
In this case the receiving node is here in the code, processing the new block without having seen the header yet.

We were validating the header in the later call to pipe::process_block().
We want to validate/process the header here, in a db transaction and a write to the MMR backend files, before we begin processing/validating the full block.

The issue was that if the full block failed validation for any reason then the entire db transaction rolled back, including the header processing. But leaving the header MMR updated with the latest header.

[antiochp]

Merging this to master.
We plan on continuing testing this on master across mainnet, floonet and usertesting to keep things as simple as possible.

[tromp]

Do we really need a linked list with 5 different variants?
Doesn't the database readily support maps from 64-bit ints to 64-bit ints?
We could map the MMR leaf position of an NRD-kernel to the next lower leaf position of an NRD-kernel with the same top k bits, if any. Besides that, we have a 2^k entry map giving the largest MMR leaf position of any NRD-kernel with those top k bits. I guess we could start with k=8 and it would take a long time before NRD kernel usage increases to the point where we'd want to migrate to k=16 in order to keep the lists relatively short.