[adamw]

Part of #3043 (point 1).

Request bodies were turned into a String and then into a C string. Bytes that are not valid UTF-8 were changed, and the body was cut at the first NUL byte. As the Content-Length header still had the original size, the server kept waiting for the rest of the body, and the request timed out.

Response bodies had the same problem: they were read with fromCString.

Now:

• request bodies (and multipart parts) are passed to curl as bytes, with an explicit size
• response bodies are read as bytes, using the length tracked by the write callback
• string bodies use their declared encoding instead of always UTF-8

Also fixed in the HttpClient backends (found by the new shared test): string bodies were always sent as UTF-8, ignoring their encoding, while Content-Length used the declared encoding.

Tests (shared HttpTest, mirrored in the native SyncHttpTest):

• "as a byte array exact" now echoes all 256 byte values
• the multipart binary part contains a NUL byte
• new: a string body with a non-UTF-8 encoding
• byte buffer and multipart encoding tests are now also run on native