[WIP] Decrease chain indexes RAM usage using Optional values

[Liquid369]

Redoing of #2315

Some users have noticed with 5.5 theres a need for some optimization, while hunting it down also figured to bring back this to assist in daemon optimization

Explanation from prior PR:

This PR migrates two uint256 fields, that aren't needed to be initialized for every block index that ever existed, to optional values. Only initializing them in the lapse of time where the data is/was available.

1. The zc accumulator checkpoint: added to the header in the block version 3 and was active up to block version 7.
2. The sapling tree root hash: added to the header in block version 8.

[zkbitcoin]

will post here findings from Valgrind (idea is to attack why 5.5.0 CPU usage has gone up noticeably over 5.4.0) in the addition to RAM

./configure -enable-debug then have it all synced up , htop will show one CPU thread being utilized constant (that shouldnt be all should have very low utilization unless disk I/O or stake found etc) and even on stake found should not be so bad

https://developer.mantidproject.org/ProfilingWithValgrind.html

[Liquid369]

Needs rebasing on a newer base, will maybe close later

[zkbitcoin]

too much machine info in the valgrind (attaching screenshot) best is to run

valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes ./pivxd

and then

kcachegrind (qcachegrind on Mac)

looks like ProcessMessage event loop consumes most CPU (also PeerLogicValidation also ProcessMNWinner)

maybe no enough breathing room is given there (like sleep yield etc), result is one CPU thread is stuck on 100% even when no new block is coming in

[zkbitcoin]

moved "CPU issue" to separate ticket as this ticker refers to RAM usage (could be related but its better to separate)

#2795