Fix large content error codes

When pushing multi-part payloads, it's quite helpful if the server
supports the header field of "Expect: 100-Continue".  What this does, is
on a large file push, allows the server to possibly reject a request
before the payload is actually sent, thereby saving bandwidth, and
giving the user more information.

Bmcweb, since commit 3909dc82a003893812f598434d6c4558107afa28 by James
(merged July 2020) has simply closed the connection if a user attempts
to send too much data, thereby making the bmcweb implementation simpler.

Unfortunately, to a security tester, this has the appearance on the
network as a crash, which will likely then get filed as a "verify this
isn't failing" bug.

In addition, the default args on curl multipart upload enable the
Expect: 100-Continue behavior, so folks testing must've just been
disabling that behavior.

Bmcweb should just support the right thing here.  Unfortunately, closing
a connection uncleanly is easy.  Closing a connection cleanly is
difficult.  This requires a pretty large refactor of the http connection
class to accomplish.

Tested:
Create files of various size and try to send them (Note, default body
limit is 30 MB) and upload them with an without a username.

```
dd if=/dev/zero of=zeros-file bs=1048576 count=16 of=16mb.txt

curl -k --location POST https://192.168.7.2/redfish/v1/UpdateService/update -F 'UpdateParameters={"Targets":["/redfish/v1/Managers/bmc"]} ;type=application/json'  -F UpdateFile=@32mb.txt -v
```

No Username:
32MB returns < HTTP/1.1 413 Payload Too Large
16MB returns < HTTP/1.1 401 Unauthorized

With Username
32MB returns < HTTP/1.1 413 Payload Too Large
16MB returns < HTTP/1.1 400 Bad Request

Note, in all cases except the last one, the payload is never sent from
curl.

Redfish protocol validator fails no new tests (SSE failure still
present).

Redfish service validator passes.

Change-Id: I72bc8bbc49a05555c31dc7209292f846ec411d43
Signed-off-by: Ed Tanous <ed@tanous.net>

0 files changed, 0 insertions, 0 deletions