Better way of JsonRpseeError creation

[dmitrylavrenov]

Closes #332

The details of JsonRpseeError - https://github.com/paritytech/jsonrpsee/blob/f83c6c55a8e2c36172cea8a5c1145e9a3b9ab377/core/src/error.rs#L57

Found 2 options to create JsonRpseeError:

• https://github.com/paritytech/substrate/blob/89498c0d756c649d71e82340bee44fcc7cfe8037/utils/frame/rpc/state-trie-migration-rpc/src/lib.rs#L171
• https://github.com/paritytech/substrate/blob/7d233c2446b5a60662400a0a4bcfb78bb3b79ff7/client/consensus/manual-seal/src/error.rs#L32

At the current moment I've implemented an example with first option as it's not required a lot of additional codes with our current implementation.

@MOZGIII What do you think? Can I continue with the first one?

[MOZGIII]

The problem with error creation is not that it's too verbose, but rather that we don't have a proper contract between our UI and the RPC server to be able to display the errors with a sensible custom logic.

[MOZGIII]

Let's discuss with @sesh92

[MOZGIII]

@sesh92, @dmitrylavrenov let's spend some time on this

[MOZGIII]

Please make sure we don't lose existing error message string customizations when we migrate to the new errors. We still need them.

[MOZGIII]

I think this needs more work but we need other things done. Let's put this on hold and move on. I also need some time to capture our requirements here more precisely, so we probably should not waste our time bashing this over and over.

Alternatively, we can merge as-is, but it might be worse than where we started... In a sense that what we had before was clearly a mess, but it was compact and could be helped relatively simply with helpers. This has some logic in it, but no explicit constraints, and is much more verbose. Yet it still feels like the logic is not clear on how we would implement this, to me it feels like reading the code from the position of the frontend engineer has become even more difficult.

---

To sum up what I've figured here so far:

1. We really care about the error data, shapes of the error data must be well-defined, and must be specified per method at the type-system level via an enum (or struct if need be) of all possible values.
2. The errors that don't have associated error data shapes are all the same to the client - in the sense that they have the same shape of message and error code. These can be described universally via a single type, and there's no need for custom data there.
3. We need to ensure the decision-making logic about the error data shapes is not nested or layered within the error implementations.
4. To enforce the compiler to complain, we cannot implement From<_> for JsonRpseeError for the types that are not considered top-level method error enums.
5. We probably don't want to implement From<_> for JsonRpseeError manually at all, and only allow a generic impl<T> From<T> for JsonRpseeError where T: SomeCustomTraitOfOurs, such that we have to implement SomeCustomTraitOfOurs and just implement SomeCustomTraitOfOurs for our error types, and implement the JsonRpseeError construction logic based on SomeCustomTraitOfOurs implementations.

---

Anyhow, this one task has taken us too much effort already, so let's put a pin in it.

We might want to do a prototype with (5), but we have better ways to spend our time now, as this is not a blocker for anyone.

[MOZGIII]

@dmitrylavrenov I managed to fix most of the issues I observed while writing #539 (comment), please check out my changes and adjust the rest of the codebase accordingly.

[MOZGIII]

How come we have merge conflicts? Let's fix them!

[MOZGIII]

Well done!