… masternode manager

dd67066 [Test] Add feature_blockhashcache.py (random-zebra)
4031fd2 [Refactor] Remove some more chainActive accesses and cs_main locks (random-zebra)
fe1d84e [Validation] Verify MN pings with cached block hashes (random-zebra)
14d3c32 [Masternode] Use cached block hashes to create mn pings (random-zebra)
f5349b9 [Cleanup] Remove global map mapCacheBlockHashes (random-zebra)
3cdb0a0 [Cleanup] Remove GetBlockHash in masternode.h/.cpp (random-zebra)
4d41910 [Masternode] Use cached block hashes to calculate the score (random-zebra)
616039e [Validation] Cycle-back when uncaching block hashes (random-zebra)
32617a7 [RPC] Add getcachedblockhashes function (random-zebra)
0de6544 [Init] Load block hashes cache at startup (random-zebra)
2237a69 [Refactor] Cache last 200 block hashes in Masternode Manager (random-zebra)
ddf63fe [Refactor] Introduce CyclingVector class (random-zebra)
2c60025 [Cleanup] Remove not needed calls to masternode.cpp GetBlockHash (random-zebra)
aa28000 [Refactor] Cache tip height in masternode manager (random-zebra)

Pull request description:

  **Problem**:
  Validation of many objects on the second layer (masternode pings, winners/scores, etc...) requires access to chainActive to get the hashes of blocks at a certain height. This is done very often (especially for masternode pings) and means holding `cs_main` lock every time, making the process slow and possibly leading to locking order inconsistencies.

  **Solution**:
  Cache the last N block hashes in the masternode manager.
  In order to implement this efficiently, we introduce a new data structure called `CyclingVector`, which is a fixed-size vector, exposing only a setter `Set(i,  value)` which modifies the index `i % N`.
  The cache is initialized at startup and updated when blocks get connected to /  disconnected from the tip.

  The size (`CACHED_BLOCK_HASHES`) is currently set a default value of 200 making it possible to validate all masternode pings (but not all masternode winners) without accessing chainActive. In the future we could add a startup flag to let the user customize this (higher cache size would, as usual, mean faster execution but higher memory usage).

  An RPC `getcachedblockhashes` is introduced, in order to print the content of the cache. This can be used later in the functional test suite for better testing.

  This PR also removes the accesses to chainActive to get the current chain-height (using a value cached in the manager).

ACKs for top commit:
  furszy:
    tested with #1916 and have run it for a while in mainnet, all looking good. Really nice, ACK dd67066 .
  Fuzzbawls:
    ACK dd67066

Tree-SHA512: 3ba56ddbf9fb37c96c1298773f1008f70ca8d0b9aac25754884805e96c7bd104f4e0c2403e49d5502117b6764c319ddd25c70bb53095b009855894d50531c056