Document chain_plugin and p2p_plugin interactions

[mvandeberg]

Noted in #2092:

In chain_plugin::accept_block(), you call the blocking get() function of a boost::future. But chain_plugin::accept_block() is in turn called by p2p_plugin_impl::handle_block(), which is a node_delegate method called by the p2p code. I think the multithreading stuff that happens as a result is all okay (basically it blocks anything else fc async'ed in the p2p code, but that's all right because all the future does push_block(), which itself shouldn't block. So the handler should always make progress as fast as the CPU can go and there's no potential for deadlock, and while lock contention can happen and blocks all p2p activity, it should never take long enough for this to be a serious problem.

But I'm not 100% sure about all that.

The above text should probably be a comment near the get() call.

The patch appears to be working locally. Nevertheless, we should confirm the behavior is as suspected and document it.

[mvandeberg]

A couple of my assumptions when I wrote #2092.

handle_block calls accept_block. Without this synchronization mechanism, if the p2p code were to block, it was already going to block because their is no multi-tasking in database::push_block. We can safely assume that blocking from bracket to bracket in accept_block is safe. Using the future was needed because the previous versions of accept_transaction and accept_block had return and exception semantics that were relied upon by callers.

It satisfies both the requirements of bracket to bracket blocking and a signal for propagating return values and exceptions.