now cache loader processes either as many files as specified by loader_files
or works no more than time specified by loader_threshold during each iteration.

loader_threshold was previously used to decrease loader_files or
to increase loader_timeout and this might eventually result in
downgrading loader_files to 1 and increasing loader_timeout to large values
causing loading cache for forever.

The bug had appeared in r3561 (fastcgi), r3638 (scgi), r3567 (uwsgi).

Previous allocation only took into account number of non-backup servers, and
this caused memory corruption with many backup servers.

See report here:
http://mailman.nginx.org/pipermail/nginx/2011-May/026531.html

The following configuration causes nginx to hog cpu due to infinite loop
in ngx_http_upstream_get_peer():

    upstream backend {
        server 127.0.0.1:8080 down;
        server 127.0.0.1:8080 down;
    }

    server {
       ...
       location / {
           proxy_pass http://backend;
       }
    }

Make sure we don't loop infinitely in ngx_http_upstream_get_peer() but stop
after resetting peer weights once.

Return 0 if we are stuck.  This is guaranteed to work as peer 0 always exists,
and eventually ngx_http_upstream_get_round_robin_peer() will do the right
thing falling back to backup servers or returning NGX_BUSY.

Flush flag wasn't set in constructed buffer and this prevented any data
from being actually sent to upstream due to SSL buffering.  Make sure
we always set flush in the last buffer we are going to sent.

See here for report:
http://nginx.org/pipermail/nginx-ru/2011-June/041552.html

If there were preread data and request body was big enough first part
of the request body was duplicated.

See report here:
http://mailman.nginx.org/pipermail/nginx/2011-July/027756.html

Previously all available data was used as body, resulting in garbage after
real body e.g. in case of pipelined requests.  Make sure to use only as many
bytes as request's Content-Length specifies.