Reject a request with both Transfer-Encoding and Content-Length

RFC 9112 6.1 forbids a Content-Length in a message that also has a
Transfer-Encoding, and lets a server "reject a request that contains
both Content-Length and Transfer-Encoding or process such a request in
accordance with the Transfer-Encoding alone", but "MUST close the
connection after responding" either way. QtHttpServer previously took
the process-with-Transfer-Encoding path implicitly (it decodes the
chunked body and ignores the Content-Length), which is a request-
smuggling vector behind a re-parsing or connection-pooling front-end.

Reject the request with 400 (Bad Request); the sendError path returns
-1 and closes the connection, satisfying the mandatory close.

Fixes: QTBUG-150550
Pick-to: 6.12 6.12.0 6.11 6.8
Change-Id: I271ab25d24440decfc2e74cc3c2aac5a37f5ded4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>