Merge r1710095, r1727544 from trunk:

core: Limit to ten the number of tolerated empty lines between request,
and consume them before the pipelining check to avoid possible response
delay when reading the next request without flushing.

Before this commit, the maximum number of empty lines was the same as
configured LimitRequestFields, defaulting to 100, which was way too much.
We now use a fixed/hard limit of 10 (DEFAULT_LIMIT_BLANK_LINES).

check_pipeline() is changed to check for (up to the limit) and comsume the
trailing [CR]LFs so that they won't be interpreted as pipelined requests,
otherwise we would block on the next read without flushing data, and hence
possibly delay pending response(s) until the next/real request comes in or
the keepalive timeout expires.
 
Finally, when the maximum number of empty line is reached in
read_request_line(), or that request line does not contains at least a method
and an (valid) URI, we can fail early and avoid some failure detected in
further processing.


* Ensure that proto_num and protocol is set in another "error out early" edge
  case. This can happen with invalid CONNECT requests as described in the PR.

PR: 58929


Submitted by: ylavic, rpluem
Reviewed  by: wrowe, covener, ylavic


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@1758672 13f79535-47bb-0310-9956-ffa450edef68