refactor: [Memory optimization] Separate chain trust from the block index

[cyrossignol]

This is part of a series of changes that optimize the memory usage of Gridcoin's block index. According to Valgrind's heap profiler (Massif), these changes will decrease memory usage of the application by over 500 MB after the final PR merges. Because these optimizations apply to every block, memory savings will continue to accrue as the chain grows. I'm breaking-up the commits into separate PRs because the branch has become too unwieldy to review in one submission.

---

This replaces the chain trust state in the block index with a custom cache to save 32 bytes of memory per block.

The cache contains two levels. The first provides quick access to trust values near the chain tip. Nodes use these values when validating new blocks. The second level stores historical chain trust values at height intervals for reporting. The trust value for a historical block can be recomputed on-demand. By tracking the historical values periodically, we can start calculating chain trust from a cached height to reduce the effort needed to reproduce it for a particular block.

[jamescowens]

Very clever! :)

[jamescowens]

This is critical for a reorg that crosses the 10000 block ladder... good.

[jamescowens]

One comment (not necessary for approval). Any particulars on the choices of the size of the short cache, and the granularity of the long cache? Did you do any performance profiling to determine these values versus the balance to memory usage, or are they educated guesses? 32 seems pretty good for the short cache, as we rarely see head of the chain forks longer than that under normal circumstances.

[cyrossignol]

I haven't had a chance to tune these for optimal performance yet. For the short cache, it's possible that we can store more than 32 entries with no observable impact. The MightContain() check could be completely unnecessary because the cost of dereferencing the pointers may cancel out the effect of the early exit. I wouldn't expect the implementation to be much of a hotspot... the chain trust comparison runs just once per block and may not even register a blip in a profiler compared to all of the other validation that happens around it. I considered 32 entries as the minimum needed for typical network behavior, and I think returns diminish sharply as we increase the size.

The long cache is more interesting. The spacing directly influences the performance of getblock and co. RPCs which might matter for services like explorers that need to query historical blocks. A shorter interval means that we can recompute chain trust more quickly for a random block. We may want to add a configuration option that enables someone to choose how the cache behaves. Setting the interval to 1 makes it as fast as the original index (with the same memory overhead). Most users won't notice the difference, though.

[jamescowens]

I don't think the juice is worth the squeeze on configurability of the long cache. You could do that on a test mule and run some tests to fine tune the value if you have the time and then hard code it.

My tests of getblock were almost instantaneous. Also the chaintrust calc for init was faster with this algorithm than the original, at least on my main workstation, which is a pretty good Intel CPU.