BlockDownloadManager needs protection against blocks that don't apply

[theoreticalbts]

It might be possible for sync to ask for a block that doesn't apply, then BlockDownloadManager clears the block out of the data structure, asks for it again, applies it again, it fails again, and so on.

We need some way to blacklist a known-bad block to break out of this loop.

We also need to be discriminatory in our error handling:

• If the block merely failed to download, e.g. due to a peer disconnect, it might be perfectly OK and downloadable from another peer.
• If the block failed to apply due to cryptographic breakage, i.e. it didn't deserialize, didn't match its ID, or topology didn't match, kick the peer but don't blacklist the block. A valid byte sequence might exist and be downloadable from another peer that satisfies the given cryptographic claims.
• We should be sure that Eve can't say "here's block zQmRst" (giving us the ID and topology of a legitimate block), feed us a block body full of garbage that doesn't hash to zQmRst, and then cause us to reject the legitimate block zQmRst from an honest peer Bob. All that should happen in this situation is we punish Eve's peer (probably this is a bad enough protocol violation for immediate disconnection rather than naughty points).

[mvandeberg]

This is irrelevant after #166