tr_peerUpdateProgress() is guessing at the progress size, but when we don't have the data size yet that guess isn't very good. Add boundary
clamps on the peer.progress field.
Previously we made sure to include stdbool.h (via transmission.h) before utp.h, since the latter used 'bool' without defining it. The new snapshot defines it unconditionally in non-C++ code, so now we need to include it first.
Once we've scored all n candidates, we sort them by score so that we can pick out the k best candidates. If n is large, sorting them can be expensive. If we use the Selection Algorithm, we select in O(n) without having to sort.
There are actually two different implementations of the byte-counting in that function: a slower implementation was added prior to 2.40 in r12918 to double-check the standard implementation. This checking was added to help smoke out a bug that was fixed in r12920, but I forgot to remove that slower implementation.
The webseed in question is downloading from an ubuntuone.com url. We ask for piece-sized ranges in a couple of different concurrent connections, and curl hints to the server that it's okay to gzip the response, or deflate it, or leave it raw. It looks like there's a bug in the server or in libcurl (or, somehow, Transmission) that's not compressing or decompressing these responses correctly -- we never get the right number of bytes in the response from libcurl. If we ask for the contents uncompressed, the download progresses towards completion.
As an aside, when testing this I noticed that deluge is a lot faster than Transmission on this torrent. In order for Transmission to reach parity here, webseed.c needs to know when it's appropriate to have more than 4 concurrent tasks and/or be able to request ranges > the torrent's piece size.
Found by llvm's static analyzer. This is a minor issue since the leak is in an automated test rather than in shipping code, but it's still better to fix it.
static-build found a potential NULL pointer dereference. The circumstances where this could get triggered don't seem very likely, but doesn't hurt to fix the warning.
scan-build found similar warnings in these two functions relating to allowing NULL pointers to be passed as arguments to functions that don't allow NULL. So now those NULL checks are made explicit before the function calls.
