LedgerDB spine optimisation

[mrBliss]

When profiling the following: adding all blocks from disk as fast as possible with block validation disabled, the LedgerDB appeared at the top of the heap/performance profile output.

I suspect it is due to the structure of the LedgerDB: it is essentially a list with a spine that is k elements long, that is traversed and reallocated each time a block is added. Instead of storing k Skip elements in the list, one Skip k element could be stored, bringing down the cost significantly.

[edsko]

It's not quite so easy, the Skip nodes do record information (they store references to the blocks that were applied there). We could avoid storing that information, at the cost of introducing more dependency between the LedgerDB and the volatile DB.

However, we can address this in quite a different way. Will open a separate ticket.

[edsko]

Obsoleted by #986.