mitigate potential DoS vector by limiting pending piece uploads

Previously there was no explicit limit on the number of piece requests
a peer could have outstanding. Each such request can potentially
consume memory up to the piece size of the torrent. Worse, since there
is no check for redundant requests, it was trivial for a peer to cause
us to consume unbounded amounts of memory by sending a long run of
requests for oversized pieces. (N.B.: Other implementations disconnect
peers for requesting more than 128 KiB at a time, but KTorrent allows
any requested size up to the piece size.)

This commit implements limits on the number of piece block uploads a
peer may have pending at any one time and on the total byte count of
those uploads. The limits are 512 uploads and 8 MiB of piece data. Any
requests received in excess of those limits are rejected. Note that
popular BitTorrent client implementations do not queue more than a
handful of piece requests at any one time, so these new limits are
expected to be proactively defensive only. That said, the author has
repeatedly observed KTorrent consuming over half a gigabyte of RAM in
queued PIECE messages waiting to be transmitted. The new limits are
intended to alleviate this pain.