Report HTTP failure codes as RPC errors if returned for an RPC call

[marmistrz]

At least in the Alchemy JSON RPC API over HTTP, rate limit errors are returned as HTTP 429. Currently these errors are converted to Error::Transport(String) and it's not possible to cleanly access the status code. Moreover, Error::Transport also means errors like failure to deserialize, whose handling will be completely different than handling of capacity limits or rate limit.

This PR changes representations of the errors returned in execute_rpc to rpc::error::Error. Since the HTTP error codes aren't any of the variants defined by jsonrpc-core, the error code will be ErrorCode::ServerError(i64).

cf. https://docs.alchemy.com/alchemy/documentation/error-reference

[tomusdrw]

Not a fan of mixing HTTP error codes (i.e. transport specific) with the ones returned by actual JSON-RPC server. What if we have a conflict and conflate an JSON-RPC error code with some HTTP error code?

I'd rather introduce a richer Transport variant, with following fields:

struct TransportError {
  /// Transport implementation self-identification.
  /// 
  /// This can be used to determine the actual transport (HTTP, WS, etc). being used if it's not statically known.
  transport_id: String,
  /// Transport-specific error code.
  code: u64,
  /// Arbitrary, developer-readable description of the occurred error.
  message: String,
}

wdyt?

[marmistrz]

JSON-RPC codes are to be negative, http/ws error codes are positive so there shouldn't be a clash, so I'm fine with both approaches. It makes some sense to use a different variant for transport and rpc errors because the former are much more retriable than the latter in many cases.

This was roughly my initial idea, however, Transport is not used in a compatible way right now as it's also used to report errors like

rust-web3/src/transports/http.rs

Line 51 in 033ac37

.map_err(|err| Error::Transport(format!("failed to build client: {}", err)))?;

or

rust-web3/src/transports/http.rs

Line 88 in 033ac37

.map_err(|err| Error::Transport(format!("failed to read response bytes: {}", err)))?;

.

We could either introduce a new variant or use code: Option<u64>.

[tomusdrw]

JSON-RPC codes are to be negative, http/ws error codes are positive so there shouldn't be a clash

JSON-RPC codes can be anything actually, the spec just defines a few reserved ranges which are negative.

This was roughly my initial idea, however, Transport is not used in a compatible way right now as it's also used to report errors like

We can either assign a code to each of such error (and expose constants with that values), use a "catch-all" 0 code for that or use Option<u64> as you suggested - I'm fine with either.

[marmistrz]

I did a slightly different implementation given that we're unlikely to get a developer-defined message and a code. I also skipped the transport_id because it would be a lot of boilerplate.

[marmistrz]

Ping, what do you think about the new implementation?

[tomusdrw]

Looks good! Please fix the tiny warnings that can be seen during the CI and we're good to go.

[tomusdrw]

Can you feature gate the import or use a direct path to prevent warnings?