[bitreq] Check utf-8 while deserializing JSON body

[tankyleo]

    [bitreq] Check utf-8 while deserializing JSON body

    While deserializing, `serde_json::from_slice` validates utf-8 as
    needed. So instead of making two passes on the response body, one
    to validate utf-8, and another to deserialize the object, we can
    let `serde_json::from_slice` check utf-8 as needed during
    deserialization.

    `Response::json` now returns `Error::SerdeJsonError` instead of
    `Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
    deserialization.

and

    [bitreq] Serialize `Request` body into `Vec<u8>`

    We avoid creating a `String` only to immediately convert it back to its
    inner `Vec<u8>`.

    This also mirrors the `serde_json::from_slice` call made when parsing a
    `Response` body as JSON.

[tankyleo]

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

[tnull]

ACK a3ae780

[TheBlueMatt]

Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

[tankyleo]

Thanks Matt see below, I have expanded the commit message.

I'm skeptical the claimed perf difference matters

The claim is that a reduction in cache misses leads to non-trivial performance gains.

We still do the same amount of work on the data.

[TheBlueMatt]

Mmm, fair enough.

ACK 2c3bbf2