epic: Error handling starting with near-providers

[jaswinder6991]

• This is a bigger change possibly breaking a lot of code.
• We need to implement it crate by crate. Refactoring examples.

[jaswinder6991]

@ckshitij, after reviewing several custom error handling techniques.
I think it is best if we do something like:

1. Implement a custom error enum in the said crate.
2. Implement error transformation using map_err() from lower level errors to higher level custom errors in the functions internally.

I referred to this technique used here in workspaces-rs.

More on the initial commit
The initial commit is an example of how we can do it.
For now, for the example, I just used JsonRpcError as one of the values for the ProviderError enum, however in real implementation we will come up with our 3-4 kinds of errors.

Action Plan

1. Define custom errors in the ProviderError enum.
2. Apply map_err transformation in the jsonrpc_provider function implementations.
3. Write examples of how this handles error better. Devs don't need to import lower level errors in their code. They just need to import ProviderError type.
4. Extend the same for near-transactions and near-accounts.

[ckshitij]

@jaswinder6991, that makes sense, but I suggest defining the error at the near-account level or as a lib-level error, which can be used for both the account and near-provider.
I'm suggesting this because the near-accounts crate will always return errors from the near-providers, as there are no errors thrown by the near-transaction crate.
What do you think?

[jaswinder6991]

@jaswinder6991, that makes sense, but I suggest defining the error at the near-account level or as a lib-level error, which can be used for both the account and near-provider. I'm suggesting this because the near-accounts crate will always return errors from the near-providers, as there are no errors thrown by the near-transaction crate. What do you think?

I would disagree here. I think Keeping errors at their respective sub crate level helps us being more detailed and granular.
I suppose near-transactions can throw errors too. I don't have an example from top of my head.

Here is what I am thinking,
The errors that are thrown from providers right now might be too much information. So we wrap them in simpler errors.

In accounts crate, I think we could create function level errors. Like function call error etc? As the crate itself is a abstraction for accounts and its functions.