Make RpcError generic

[gregdhill]

I am unable to upgrade from 0.23.0 to 0.24.0 because we lost the RpcError type (here) propagated from jsonrpsee. We use this to specifically match custom errors for transaction invalidity and for when the background service needs to be restarted. Instead of converting this error into a string the RpcClientT trait should have a generic parameter for the error.

[jsdw]

We'll have to have a think about that; I do see that we lose some information now which sucks, but adding a generic parameter would propagate through the entire codebase again, so it'd definitely be preferably to avoid that if we can!

Perhaps we should box the error if possible into a Box<dyn Error> type thing, so at least you can recover the underlying error by a cast, and we can avoid the generic proliferation; what do you reckon?

[lexnv]

To quickly unblock the transition to 0.24.0 one could try to match those strings.
The error string should contain enough information, and if it doesn't we should point that for a jsonrpsee update.
It might not be ideal, but just a temporary fix until we roll a Box<dyn Err> as James mentioned.

[gregdhill]

I want to avoid comparing strings for obvious reasons, but we also need to parse the JsonRPC error object in some cases. The approach you have suggested @jsdw makes sense to me!

[jsdw]

@gregdhill would you be able to check out #694 and confirm that it addresses your needs?

[gregdhill]

LGTM, thanks @lexnv @jsdw!