Since PeerManager takes a lock on cs_main in order to verify proofs, there is a potential deadlock if cs_main
is taken (commonly done in validation code) and then cs_peerManager is taken (commonly done via Processor).
PeerManager takes a lock on cs_main in order to verify proofs, making the typical lock order:
cs_peerManager (processor.cpp) -> cs_main. As avalanche post consensus develops, its easy to accidentally
introduce an inverted lock order by accessing the avalanche API in validation code:
cs_main (validation.cpp) -> cs_peerManager (processor.cpp).
This patch introduces additional low-hanging-fruit compile and runtime assertions to help catch these as quickly as possible.