The WINDOW_UPDATE frame could be left in the output queue for an indefinite
period of time resulting in the request timeout.

This might happen if reading of the body was triggered by an event unrelated
to client connection, e.g. by the limit_req timer.

This prevents possible processing of such frames and triggering
rb->post_handler if an error occurred during r->request_body
initialization.

Particularly this prevents sending WINDOW_UPDATE with zero delta
which can result in PROTOCOL_ERROR.

Also removed surplus setting of no_flow_control to 0.

Refusing streams is known to be incorrectly handled at least by IE, Edge
and Safari.  Make sure to provide appropriate logging to simplify fixing
this in the affected browsers.

After the 92464ebace8e change, it has been discovered that not all
clients follow the RFC and handle RST_STREAM with NO_ERROR properly.

Notably, Chrome currently interprets it as INTERNAL_ERROR and discards
the response.

As a workaround, instead of RST_STREAM the maximum stream window update
will be sent, which will let client to send up to 2 GB of a request body
data before getting stuck on flow control.  All the received data will
be silently discarded.

See for details:
http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008143.html
https://bugs.chromium.org/p/chromium/issues/detail?id=603182

A client is allowed to send requests before receiving and acknowledging
the SETTINGS frame.  Such a client having a wrong idea about the stream's
could send the request body that nginx isn't ready to process.

The previous behavior was to send RST_STREAM with FLOW_CONTROL_ERROR in
such case, but it didn't allow retrying requests that have been rejected.

No functional changes.

This prevents forming empty records out of such buffers.  Particularly it fixes
double end-of-stream records with chunked transfer encoding, or when HTTP/2 is
used and the END_STREAM flag has been sent without data.  In both cases there
is an empty buffer at the end of the request body chain with the "last_buf"
flag set.

The canonical libfcgi, as well as php implementation, tolerates such records,
while the HHVM parser is more strict and drops the connection (ticket #950).