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.