Bug 5282: Randomize HTTP request order and pipeline depth.

This is an experimental defense against Website Traffic Fingerprinting:
http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf

See:
https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting

This patch is different from the approach described in that post, as well as
the 10.x ESR patch, as the pipelining code has changed significantly between
the time of writing of that post and Firefox 17.

The main control nob for this patch is now the about:config pref
network.http.pipelining.max-optimistic-requests. The value of that pref
represents the minimum number of pipelined requests we will attempt to batch
together.

The total outstanding pipeline size is randomized between that value and
network.http.pipelining.maxrequests on a per-host basis.

Care must be taken when evaluating this defense, as pipeline behavior is
extremely sensitive to browser performance. In fact, a debug build alone is
enough to significantly impair request availability to the pipeline (due
slower document parsing and rendering). For this reason, we provide two
separate debug log defines. For most evaluation circumstances, you want to
define only WTF_TEST in an optimized build to only log request order,
combination behavior, and cases where the pipeline is forcibly disabled.

This patch may also have some minor impact on SPDY request order, but the SPDY
implementation has not been altered directly. It has several stream queues
that may also benefit from reordering and batching, as well as a more compact
request representation that will allow more requests to be packed inside Tor
cells. If you have interest in evaluating SPDY in a study of Website Traffic
Fingerprinting, please contact me.