If client closed connection in ngx_event_pipe_write_to_downstream(), buffers
in the "out" chain were lost.  This caused cpu hog if all available buffers
were in the "out" chain.  Fix is to call ngx_chain_update_chains() before
checking return code of output filter to avoid loosing buffers in the "out"
chain.

Note that this situation (all available buffers in the "out" chain) isn't
normal, it should be prevented by busy buffers limit.  Though right now it
may happen with complex protocols like fastcgi.  This should be addressed
separately.

The default value is 32 AIO simultaneous requests per worker. Previously
they were hardcoded to 1024, and it was too large, since Linux allocated
them early on io_setup(), but not on request itself. So with default value
of /proc/sys/fs/aio-max-nr equal to 65536 only 64 worker processes could
be run simultaneously. 32 AIO requests are enough for modern disks even if
server runs only 1 worker.

Fixed nearby grammar errors.

does not support them.  Previously worker just exited.

syscall(2) uses usual libc convention, it returns -1 on error and
sets errno. Obsolete _syscall(2) returns negative value of error.

Thanks to Hagai Avrahami.

As long as ngx_event_pipe() has more data read from upstream than specified
in p->length it's passed to input filter even if buffer isn't yet full.  This
allows to process data with known length without relying on connection close
to signal data end.

By default p->length is set to -1 in upstream module, i.e. end of data is
indicated by connection close.  To set it from per-protocol handlers upstream
input_filter_init() now called in buffered mode (as well as in
unbuffered mode).

The ngx_chain_update_chains() needs pool to free chain links used for buffers
with non-matching tags.  Providing one helps to reduce memory consumption
for long-lived requests.

Setting read->eof to 0 seems to be just a typo.  It appeared in
nginx-0.0.1-2003-10-28-18:45:41 import (r164), while identical code in
ngx_recv.c introduced in the same import do actually set read->eof to 1.

Failure to set read->eof to 1 results in EOF not being generally detectable
from connection flags.  On the other hand, kqueue won't report any read
events on such a connection since we use EV_CLEAR.  This resulted in read
timeouts if such connection was cached and used for another request.

If connection has unsent alerts, SSL_shutdown() tries to send them even
if SSL_set_shutdown(SSL_RECEIVED_SHUTDOWN|SSL_SENT_SHUTDOWN) was used.
This can be prevented by SSL_set_quiet_shutdown().  SSL_set_shutdown()
is required nevertheless to preserve session.