Currently, reactor.Receive method runs in the same thread as the p2p recv routine, i.e., p2p recv routine makes a blocking call to the corresponding reactor.Receive method. There are several issues with this design:

1. failure in any reactor.Receive method (for example in mempool or blockchain reactor) might lead to network stopping to produce blocks.
2. while we are blocked on reactor.Receive that is sometimes quite costly (see for example respondToPeer method of blockchain reactor as part of bcBlockRequestMessage handling) no other message from that peer connection is being processed (although it might be completely received).

Is there any good reasons why we shouldn't enqueue message upon reception to a corresponding reactor so it can be processed in parallel with delivery of new message and with message handling of other messages from different reactors? It feels like this will be more secure design (regarding 1)) and potentially lead to overall better performance (regarding 2)).

#1210.