Fix MN activation when the node received the mnb before initialize the MN.

[furszy]

If the node already has the MN stored and the activation process is triggered (via the startup flag or the RPC command), the node's activeMasternode will get stalled waiting until (1) the MN list gets cleaned/refreshed and someone else in the network sends the MN again or (2) until someone else enable the MN (which is not possible as this node is being enabled solely to send the ping to enable the MN..)

This is the reason why someone in the past added the activeMasternode::EnableHotColdMasterNode call inside the mnb message receive (which now is redundant), to force the activation as the MN enablement process was totally stalled.

[random-zebra]

Concept ACK.
Although the remote node should complete mnsync before checking, as it might have stale data at startup.

This is the reason why someone in the past added the activeMasternode::EnableHotColdMasterNode call inside the mnb message receive (which now is redundant), to force the activation as the MN enablement process was totally stalled.

I think there might be more to this.
For example, suppose that the controller sends a new mnb for the same masternode (same IP, same key) but referencing a different collateral utxo. This way the remote node can update its vin without having to be restarted.

[furszy]

true, added a tier two sync status check before enable the MN in the init process. Once it's synced, the ManageStatus function will automatically enable it. And if it's already synced, like it usually happen with the on-demand MN init, it will start it right away.

[random-zebra]

ACK 6a43186