ref(service): Classify service errors by kind

[lcian]

This is a different take on giving us more control over HTTP status codes when erroring out from the service layer that doesn't make callers more verbose, but actually less so in some cases.

1. ServiceError variants gain a kind that's used to determine log level and HTTP status code when converting to ApiErrorResponse. The kind is implemented via https://crates.io/crates/derive-error-kind which lets us do it concisely via a error_kind attribute on each variant. This is a very simple proc macro that we could also vendor in.

2. Existing constructors for specific Error variants remain, and map to ErrorKind::Internal.

3. For errors that could map to different kinds depending on the context, we also introduce additional intermediate wrapper types (needed to support different kinds) and constructors on ServiceError.
   Namely: reqwest_transparent (alternative to the existing reqwest helper), serde_client (alternative to the existing serde helper), and the metadata/metadata_client pair.

4. As a special case, we implement From<std::io::Error> for Error so that callers can keep using ? to propagate io errors. That's because so far we always want io::Error to map to ErrorKind::internal, so there's no reason to make callers more verbose in this case.
   This has the added benefit that the impl can encapsulate the unpack_client_error logic, to avoid repeating it in every caller.

5. Also renames ClientError to ClientStreamError as that's a less confusing name.

Refs FS-358

[linear-code]

FS-358

[lcian]

Improvement: here we have a valid Metadata, it's therefore our fault if we fail to serialize it, and now we can correctly map this to an internal error as opposed to always blaming the client.