feat(jsonrpc): add error data field from JSON RPC spec

[glihm]

Currently, when the JSON RPC error is ContractError(40), we loose the data field that is only present for the CONTRACT_ERROR error type from the spec.

This PR aims at adding the revert_error that is present in data to the error message.
I've tried to modified the structure, but due to the current state of the spec, @xJonathanLEI do you think that is enough, or we should prepare a struct that can be forward compatible with other possible error coming in the future?

In anyway, it's useful to have a more explicit error message in the case of contract error. We may add a revert_reason field?

Any comment feedback very welcomed!

[glihm]

@xJonathanLEI changed this one to also add the data error when the error is a more generic one and not only starknet contract error.

[xJonathanLEI]

When you say there's a data field in the CONTRACT_ERROR variant, you're actually referencing v0.5.x of the specs (btw please use permalink instead when referencing files). starknet-rs supports v0.4.0 only at the moment. It's wrong to expect a data field.

This PR shouldn't be merged at least until we move to v0.5.x.

[glihm]

When you say there's a data field in the CONTRACT_ERROR variant, you're actually referencing v0.5.x of the specs (btw please use permalink instead when referencing files). starknet-rs supports v0.4.0 only at the moment. It's wrong to expect a data field.

This PR shouldn't be merged at least until we move to v0.5.x.

You're totally right for the CONTRACT_ERROR variant. And the we shouldn't add the data behavior on this specific error until v0.5.x.

However the PR also addresses the JSON RPC spec, where the error object contains a data field that we are not using as it can be omitted but can also be present following the spec. https://www.jsonrpc.org/specification#error_object

Can we please consider this part of the PR and I remove the CONTRACT_ERROR part?

[glihm]

I Will rename and and change the context accordingly to have a better scope on this PR.

[glihm]

@xJonathanLEI I've changed the PR to only address the compatibility with the JSON RPC spec (not the JSON RPC of starknet, but the underlying protocol).
When the new Starknet JSON RPC spec is supported, we will be able to leverage this field for the contract error or any other coming in the future.

WDYT?

[xJonathanLEI]

As much as I agree that we definitely need the ability to parse the data field from JSON-RPC errors, I don't think representing everything as a String is the optimal way of doing this.

[xJonathanLEI]

Superseded by #513.