Guard oversized HTTP body callbacks

[bettercallsaulj]

Guard oversized HTTP body callbacks

Issue

The HTTP codec body callback created or appended std::string data directly from parser callback arguments without first validating the callback payload.

If the parser callback received a null data pointer with a non-zero length, or an unexpectedly large body chunk, the codec could allocate a very large string or dereference invalid input. Allocation failure could escape the callback and terminate the event thread instead of being converted into a parser error.

This was especially risky for native HTTP/SSE client flows because body callbacks run on the transport read path.

How to reproduce

1. Build the SDK with HTTP transport enabled.
2. Exercise the HTTP codec with a malformed or hostile response/request body callback.
3. Feed a body callback with one of these inputs:

data = null, length > 0

or

length > 16 MiB for a single HTTP body callback chunk

4. In client mode, trigger this through a response body. In server mode, trigger it through a request body.

Before the fix, the codec tried to construct or append body data directly. A large chunk could force excessive allocation, and an allocation failure could propagate out of the parser callback instead of becoming a controlled parser failure.

Expected fixed behavior

The body callback now accepts zero-length chunks as a no-op, rejects null non-empty chunks, and rejects chunks larger than the codec limit.

For accepted chunks, string construction and body accumulation are wrapped so std::bad_alloc becomes an HTTP parser callback error. The event thread should not terminate from an uncaught allocation failure.

Regression check

A regression test should cover:

1. zero-length body callback succeeds;
2. null data with non-zero length returns parser error;
3. body chunks over the configured limit return parser error;
4. allocation failure paths report an error through the codec instead of throwing out of the callback.