Move error decoding out of Client, support custom decoders

[sfackler]

a la https://github.com/palantir/dialogue/blob/156b8d91f36e68fbad857fcc8fe0fa0ca57a90d8/dialogue-annotations/src/main/java/com/palantir/dialogue/annotations/ErrorDecoder.java

[TheKeveloper]

It seems to me like our DeserializeResponse and AsyncDeserializeResponse already force custom error decoding by returning a Result in deserialize. I guess one small improvement would be to make the error type generic instead of a conjure error if we wanted to handle arbitrary types of errors?

[sfackler]

The issue here is that the Client is currently internally responsible for converting all non-2xx responses into Errs. If we moved or disabled that we'd be able to allow the caller to control that logic more directly. I'm not so concerned about the Rust error type.

[TheKeveloper]

Ah I think I see. So we'd want to restrict the errors returned by Client to be just transport errors, then update the response deserializer implementations to decode the raw response status code and return an error if one should be returned. Then we'd want to update the client implementation in conjure-rust-runtime to avoid parsing the status code in an error and instead just let that be handled downstream.

Is that generally what you were thinking?

[sfackler]

Yep, though I think it'll take some design work to figure out how it should interact with Conjure's internal retry logic.