Reject different HTTP requests with unusual framing (#753)

Reject different HTTP requests with unusual framing (#753)

... and remove support for request_entities.

Squid now follows the following (approximate) rules when checking HTTP
request framing. The first matching rule wins.

* HTTP requests with a Transfer-Encoding:chunked header, including GET
  and HEAD requests with that header, are accepted. No changes here.

* HTTP requests with unsupported Transfer-Encoding values are rejected
  (Squid replies with HTTP 501 "Not Implemented"). No changes here.

* HTTP requests having conflicting Content-Length values are rejected
  (Squid replies with HTTP 400 "Bad Request"). No changes here.

* HTTP/1.0 and HTTP/0.9 POST and PUT requests without a valid
  Content-Length header are now rejected (Squid replies with HTTP 411
  "Length Required"). All of these were allowed before.

* HTTP/1.0 GET and HEAD requests with a Content-Length:0 header are now
  rejected (Squid replies with HTTP 400 "Bad Request"). All of these
  were allowed before.

* HTTP/1.0 GET and HEAD requests with a positive Content-Length header
  are now rejected (Squid replies with HTTP 400 "Bad Request"). All of
  these were allowed before if and only if the request_entities
  directive was explicitly set to "on".

There are no other framing-related HTTP request restrictions. Prior to
these changes, HTTP/1.1 GET and HEAD requests with a positive
Content-Length header were rejected unless the request_entities
directive was explicitly set to "on". The following configuration sketch
keeps rejecting those requests:

    acl getOrHead method GET HEAD
    acl withContentLength req_header Content-Length .
    http_access deny getOrHead withContentLength

The new restrictions were added due to possibility of cache corruption
attacks and other security issues related to HTTP request framing.

The request_entities directive was removed to simplify decision logic.

Some developers believe that these changes should be accompanied by
configuration options that allow admins to bypass (most of) the
previously absent restrictions. However, these developers do not know of
any important use cases that these changes break, and such cases may not
even exist. The authors insist on these security-driven changes.