Support variable size PMMR (optional size_file)

[antiochp]

This PR replaces a big chunk of #1260 by implementing an optional size_file alongside the data_file. The size_file can be thought of as an index into the data_file allowing random access by position across elements with variable size.

How does this work?

To read an entry at position n we first read the size_entry at position n then use this to read size bytes at the given offset. This allows us to do efficient random access into the data_file via two reads (one in size_file one in data_file).

The size_file itself is simply implemented as a fixed size data_file containing size_entries.

Each size_entry consists of -

• offset (u64, 8 bytes)
• size (u16, 2 bytes)

The size_file will add an additional 10 bytes of data for each kernel in the kernel MMR.
But this will (eventually) allow us to save 8 bytes of lock_height on most kernels and 8 bytes of fee on all coinbase kernels.

Currently Implemented

• The txhashset now instantiates a "variable size" backend for the kernel MMR.
• All other MMRs are "fixed size".
• The kernel MMR supports variable size elements but they are all currently the same size (fully backward compatible with all existing 1.0.x and 1.1.x nodes).
• The size_file is (re)built locally (and does not participate in sync process).

Future Direction

• Persist variable size kernels to support -
  • optional lock_height on HeightLocked kernels
  • optional fee on non-coinbase kernels

Eventually aim is to support "relative kernels" which will in turn allow "relative lock_heights" to be implemented.
This will require us to store a related kernel excess commitment alongside some kernels (kernel K1 is relative to kernel K2) and we cannot currently do this with fixed size kernels in the kernel MMR as we have nowhere to store this relationship.

---

TODO -

• Tested locally in various situations using local usernet
• Tested against floonet
• Tested against mainnet
• Windows testing (fast sync, file write/overwrite/replace edge cases etc.)

[ignopeverell]

I think it makes more sense to have it on 1.1.0 only to limit merge issues now?

[antiochp]

Closing - targeting 1.1.0 only with #2734.