Remove mapBlockSource #7887

This refactor is part of larger work I'm doing for faster block relay. It was inspired by noticing that mapBlockSource is redundant with mapBlocksInFlight -- mapBlocksInFlight already contains a mapping from blockhash to peer id.

mapBlockSource was used to DoS-ban peers that send us bad blocks, but the banning logic was sometimes broken-- InvalidBlockFound could DoS ban, and then another ban for the same bad block would be applied in ProcessMessages. Just removing mapBlockSource is the simplest fix.

There is a corner case where a peer might have been banned before, but will not get banned now: if we get an out-of-order block from a peer that double-spends an output spent in a previous block that we don't yet have. The requirement that the block have valid proof-of-work prevents this from being a practical DoS attack.

ProcessNewBlock loses it's *pfrom argument, which is nice-- ProcessNewBlock shouldn't care about networking stuff.

This makes CBlockReject dead code.

p2p-fullblocktest.py fails and would require update: Block not in reject map: 13572f60d7b17134219196b3dba1c8f175782feac4e4e02d5bd957d7b946e0e6 https://travis-ci.org/bitcoin/bitcoin/jobs/123437467#L4534

This means no reject messages or misbehaviour/banning will trigger anymore for any block validation rules (after their header was accepted). Is that intentional?

@kazcw : Indeed, it does make CBlockReject dead code, I'll remove it, too. @jonasschnelli : I'll fix p2p-fullblocktest, don't know how I managed not to run it. @sipa : Rejection and DoS still happens in the else if (strCommand == NetMsgType::BLOCK ...) condition in ProcessMessages, if ProcessNewBlock returns an invalid validation state.

I may be mis-reading the code (in which case there needs to be a big comment in the code explaining why it doesn't do what it says), but ProcessNewBlock calls AcceptBlock, which calls AcceptBlockHeader and CheckBlock and ContextualCheckBlock and ActivateBestChain with the same validation state. Looking again... ActivateBestChainStep overwrites an invalid validation state if ConnectTip fails? WTF?

I wrote an alternative version of this pull request that uses mapBlocksInFlight to identify the peer that sent us a block (using Boost.ScopeExit and modifying ProcessNewBlock so the entry in mapBlocksInFlight isn't removed until all of the validation is done).

@gavinandresen ProcessNewBlock's state only returns errors resulting from failure to add it to the block index (header invalid, checktransaction fails, system error when writing to disk, ...). Activation of the best block is treated as something happening in the background, and its errors are reported via InvalidBlockFound (specifically so errors don't get reported twice).

Closing this for now-- but I put refactoring the way validation errors are reported from ProcessNewBlock on my mental TODO list (the goal I'm working towards is parallel validation of new blocks).