Prune peers that send too many consecutive DONT_HAVEs

[dirkmc]

Fixes #257

A potential issue I see with this simplistic approach is that if for example we are downloading a big file, the DAG will be split into many subbranches, so if for example

• there are two peers
• the DAG is split into two sub-branches from the root
• peer A has all blocks
• peer B has one sub-branch with half the leaf blocks

In this case a situation may arise where

• peer B will repeatedly respond with DONT_HAVE at the beginning
• peer B's consecutive DONT_HAVE limit will be exceeded
• peer B will be removed from the session

If peer B's latency was lower than peer A, then it would have been faster to keep peer B in the session.

@Stebalien I'm not so familiar with the structure that is produced by chunking, is this likely to be a problem in practice?

[Stebalien]

That could happen if both have the root, peer A has everything, peer B has bar, and we try to download foo first.

.
├── bar
│   ├── big1
│   ├── big2
│   ├── big3
│   ├── big4
│   ├── big5
│   └── big6
└── foo
    ├── small1
    ├── small2
    ├── small3
    ├── small4
    ├── small5
    ├── small6
    └── small7

We'll quickly download foo (small), then take longer downloading bar. However, we do also randomly broadcast a single want-have to all connected peers periodically. If we're downloading a large enough dataset for this to matter, I expect we'll hit that timeout and add peer B back into the session.

[Stebalien]

I'd consider dropping this to something really small for now (4?).