Pre-emptive rejection of requests

The current algorithm for deciding whether to accept or reject a request in 0.7 is implemented in Node.shouldRejectRequest().

Details:
- Arbitrary maximum of 100 running requests and 100 running inserts. This is partly to minimize thread usage (the node does not have infinite resources) and prevent some of the absurd spikes we were seeing. Yes, it sucks.
- Check the ping time. When we say ping time we mean the time it takes for an average packet to be acknowledged, not the ICMP ping time (which is likely to be inaccurate as some ISPs prioritise it to make themselves look good). If the ping time is over 1500ms, we reject the request. If it is between 700ms and 1500ms, there is a sliding scale for the probability of rejecting the request.
- Check the bandwidth limiter delay. Only data transfer packets are throttled at present. We calculate an average time by which these packets are delayed by the bandwidth limiter before being sent. This is the bwlimitDelayTime. This is preferable to having an arbitrary limit on the number of transferring requests because we don't know how long it will take for the next packet to arrive. If the bwlimitDelayTime is over 2000ms, we reject the request. If it is between 1000ms and 2000ms we probabilistically reject the request.
- Check the bandwidth predictors. We keep statistics on the expected number of bytes sent and received by each type of request. We keep a separate token bucket, the high level bandwidth limiter, as distinct from the low level bandwidth limiter, which we use to ensure that the average bandwidth used by accepted requests (as opposed to the bandwidth used over a second) is kept within the bandwidth limit. Tokens are added to this bucket as fast as we are allowed to send bytes, and the predicted number of bytes for a request are removed when we accept a request. The size limit is currently the maximum of one minute's bandwidth usage and 640kB. We have one of these for input and one of these for output (there is no low-level input throttling, but there is high-level input throttling). This mechanism applies to locally originated requests as well as incoming requests. This mechanism should keep bwlimitDelayTime down and ensure we only accept as many requests as we can handle in a reasonable time.
- We check whether we have enough memory available (at least 3MB or 1%). This was recently introduced and will probably be removed, as requests use very little memory.
- We accept the request.