fix: remove app-layer usage of transport error

[prestwich]

Motivation

TransportError should capture Transport-layer errors, not application or RPC semantics errors. RPC semantics errors should be captured by RpcError (note that TransportErrorKind instantiates an RpcError<TransportError>, not a TransportError). Application errors should be captured by either RpcError (e.g. when the application expects a non-null response) or by an ErrResp

Solution

• Remove usages of TransportErrorKing::custom_str
• Remove MissingReceipt variant from TransportError
• Add NullResp variant to RpcError

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[mattsse]

I think this makes sense

[mattsse]

I think this could also fail with a
-32601, message: Method not found

rpc error for the fee_history call?

some providers also return -32600, message: Unsupported method:

so perhaps we should be less restrictive here and also check the rpc error response?

[prestwich]

We could assume any error response is also a reason to retry as a legacy

i'm not 100% convinced that retrying as legacy is the correct thing to do here, as forcing legacy could conflict with users who have already put blobs onto their transaction request. We may want to just return errors here

[mattsse]

I think that makes sense, so the unsupported feature check is okay because this looks at the base fee value of the header

[prestwich]

we need to write down somewhere that 1559 is somewhat privileged by the library in ways that other tx types and HF features are not. I.e. we generally assume that 1559 is active and proactively attempt to use it in gas estimation even tho we acknowledge that there may be chains that don't support it