Non-daemon mode is currently used by supervisord, daemontools and so on
or during debugging. The NOACCEPT signal is only used for online upgrade
which is not supported when nginx is run under supervisord, etc.,
so this change should not break existant setups.

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.

NetBSD 5.0+ has SO_ACCEPTFILTER support merged from FreeBSD, and having
accept filter check in FreeBSD-specific ngx_freebsd_config.h prevents it
from being used on NetBSD.  Therefore move the check into configure (and
do the same for Linux-specific TCP_DEFER_ACCEPT, just to be in line).

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

Previously only first log level was required to be correct, while error_log
directive in fact accepts list of levels (e.g. one may specify "error_log ...
debug_core debug_http;").  This resulted in (avoidable) wierd behaviour on
missing semicolon after error_log directive, e.g.

    error_log /path/to/log info
    index index.php;

silently skipped index directive and it's arguments (trying to interpret
them as log levels without checking to be correct).

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