Fix passing incomplete body to parsers on connection abruptly closed

[rwalerow]

This PR fixes the last part of #4169

When client send partially declared body and than connection closes for any reason
Server reports issue and clears already read request and proceeds with a regular operation.

[adamw]

This is an automated review.

The fix works for the Netty Future and Sync servers: a truncated body no longer reaches the codec. But #4169 is not fully fixed yet:

1. Cats and ZIO Netty servers are not covered. They don't use SimpleSubscriber. NettyCatsRequestBody.publisherToBytes and NettyZioRequestBody.publisherToBytes read the body via Fs2StreamCompatible.fromPublisher / ZioStreamCompatible.fromPublisher, which don't check the length, so a truncated body still goes to the codec. The repro in Chunked transmission lasts longer than timeout #4214 used the Cats server. Maybe the check should live in a place shared by all backends.
2. Zero body bytes received → request hangs. If the connection closes after the headers but before any body bytes, buffers is empty, onComplete hits case _ => (), and the promise is never completed. This should also fail when contentLength.exists(_ > 0).
3. File bodies: FileWriterSubscriber has no length check either, so a truncated upload is passed on as a complete file.

Minor:

• In onComplete, the second case's guard contentLength.forall(_ == totalLength) is always true once the first case didn't match; length > 0 is enough.
• The new test covers only the Future server. It also waits a fixed 500ms and then checks the logic wasn't called, so it could pass even without the fix if the logic just hasn't run yet. Tests for Cats, ZIO and Sync would help.

[adamw]

This is an automated review (follow-up, at edbf85bca).

All points from the previous review are addressed. Checking the length in SubscribeTrackingStreamedHttpRequest covers every backend (Future, Cats, ZIO, Sync) and every body type (bytes/string, file, multipart, stream). Zero body bytes no longer hangs, and copying buffers in CopyingPublisher avoids leaks when the stream fails. The ZIO path is fine without it: zio-interop-reactivestreams emits queued chunks before failing, so they still get released.

Remaining, minor:

1. No end-to-end test for the reported case: a truncated string/JSON body must not reach the codec or the server logic. The Future test from the first version was removed. Right now only the subscriber unit test and the Cats streaming test exist. One test in the shared server tests (send a partial body with a large Content-Length, check the logic never runs) would cover all backends.
2. Sync multipart now copies each chunk to an array and wraps it back into DefaultHttpContent, which is one more copy than before. Probably fine, just noting it.