Fix "Unknown new rules activated" Error & Uninitialized Variable nMinerConfirmationWindow, Revert Changes

[JaredTate]

After digging in deep into the "Unknown new rules activated" issue we have actually revealed multiple unknown issues we can now correct. So I really appreciate Barry's help as well as others feedback on this. We definitely have some great collaboration here. This PR is a continuation of Barrys PR: #75

The issue with adding:

            // dont trigger 'unknown new rules' warning if the bit falls within
            // the block algo version range (enum in primitives/block.h)
            if (bit <= BLOCK_VERSION_ALGO) continue;   

Is that then causes an issue for potential future algo swaps as there are reserved bits below BLOCK_VERSION_ALGO.

enum {
    // primary version
    BLOCK_VERSION_DEFAULT        = 2, 

    // algo
    BLOCK_VERSION_ALGO           = (15 << 8),
    BLOCK_VERSION_SCRYPT         = (0 << 8),
    BLOCK_VERSION_SHA256D        = (2 << 8),
    BLOCK_VERSION_GROESTL        = (4 << 8),
    BLOCK_VERSION_SKEIN          = (6 << 8),
    BLOCK_VERSION_QUBIT          = (8 << 8),
    //BLOCK_VERSION_EQUIHASH       = (10 << 8),
    //BLOCK_VERSION_ETHASH         = (12 << 8),
    BLOCK_VERSION_ODO            = (14 << 8),
};

If anything it should be Odo specific:

            // dont trigger 'unknown new rules' warning if the bit falls within
            // the block algo version range (enum in primitives/block.h)
            if (bit == BLOCK_VERSION_ODO) continue;   

However the easier fix is much more nuanced. It appears BTC devs ran into similar issue and the problem is a un initialized variable "nMinerConfirmationWindow" and we need to hard code the consensus.MinBIP9WarningHeight. Bitcoin devs corrected and fixed a similar issue here: bitcoin/bitcoin#17449

So basically this needs changed

consensus.MinBIP9WarningHeight = consensus.OdoHeight + consensus.nMinerConfirmationWindow;   

To

consensus.MinBIP9WarningHeight = 9152640; // Odo height + miner confirmation window,;   

Barry identified a message in his PR about VERSIONBITS_NUM_BITS_TO_SKIP which shows we never fully reverted test changes made in 2017.

VERSIONBITS_NUM_BITS_TO_SKIP was actually reverted the very next day they were proposed, however the one thing never reverted was static const int32_t VERSIONBITS_NUM_BITS = 16.

That should be 29. So 29 should be the max number of potential version bits. Also, Barrys commits in here fully bury Odocrypt deployment as they should be.

Thanks to everyone for your help looking into this. This was the last major issue I have been able to identify with 8.22. My recommendation is we get this merged into the develop branch and test mining, and taproot activation. Once there we are done with BTC v22 merge and can move on to other v8.22 enhancements.

[gto90]

ACK

Great work on this @JaredTate and @barrystyle . I tested and can confirm there are no further "Unknown new rules activated" messages.

[ycagel]

cACK