[Bug] Incorrect calculation of rc_consensus_hash leads to nodes not talking to each other via StackerDB

[jcnelson]

The value rc_consnsus_hash is intended to capture the ongoing Stacks tenure ID. It gets used to tag StackerDB inventory and chunk messages as originating from a node with a particular StackerDB configuration view.

Unfortunately, rc_consensus_hash is incorrectly calculated in Nakamoto as the ongoing tenure ID at the time of the canonical sortition. So when the p2p thread loads rc_consensus_hash as part of a call to SortitionDB::get_burnchain_view(), it may get an rc_consnsus_hash that corresponds to an arbitrarily old Stacks tenure even if the node has since caught up.

The fix for this is to simply use the tenure ID of the canonical Stacks tip. However, we will need to get at least one mining node and >70% signing nodes to upgrade at the same time to safely deploy the fix.