Patch by Peter Smit.

"start" parameter value.

Big POST (not fully preread) to a

    location / {
        return 202;
    }

resulted in incorrect behaviour due to "return" code path not calling
ngx_http_discard_request_body().  The same applies to all "return" used
with 2xx/3xx codes except 201 and 204, and to all "return ... text" uses.

Fix is to add ngx_http_discard_request_body() call to ngx_http_send_response()
function where it looks appropriate.  Discard body call from emtpy gif module
removed as it's now redundant.

Reported by Pyry Hakulinen, see
http://mailman.nginx.org/pipermail/nginx/2011-August/028503.html

Test case:

   location / {
       error_page 405 /nope;
       return 405;
   }

   location /nope {
       return 200;
   }

This is expected to return 405 with empty body, but in 0.8.42+ will return
builtin 405 error page as well (though not counted in Content-Length, thus
breaking protocol).

Fix is to use status provided by rewrite script execution in case
it's less than NGX_HTTP_BAD_REQUEST even if r->error_status set.  This
check is in line with one in ngx_http_script_return_code().

Note that this patch also changes behaviour for "return 302 ..." and
"rewrite ... redirect" used as error handler.  E.g.

    location / {
        error_page 405 /redirect;
        return 405;
    }

    location /redirect {
        rewrite ^ http://example.com/;
    }

will actually return redirect to "http://example.com/" instead of builtin 405
error page with meaningless Location header.  This looks like correct change
and it's in line with what happens on e.g. directory redirects in error
handlers.

Whitespaces after chunk size seems to be be allowed by the "implied *LWS" rule
and emitted by some servers.