feat: implement JsonRpc transport for batch requests

[thetheveloper]

Introduces JsonRpc batching requests described in #593

[thetheveloper]

Thank you @tcoratger for the review. All review comments addressed in the latest commit.

[xJonathanLEI]

Do we have to resort to serde_json::Value here? I generally dislike having that as part of the interface.

[thetheveloper]

Good question. Not necessarily, however this function was specifically introduced for this approach - to return generic JSON type based on the type returned. Otherwise, we'd have to create custom types for this and that would limit the ways we can call it

It's possible to change it if you prefer any other direction

[tcoratger]

@adrienlacombe For me this PR is ready to be merged but I think this discussion still is opened

[adrienlacombe]

ty @tcoratger , @xJonathanLEI can you please let us know your thoughts? ty

[tcoratger]

@thetheveloper can you rebase to trigger the ci again? I think this should be good now

[thetheveloper]

@thetheveloper can you rebase to trigger the ci again? I think this should be good now

@tcoratger rebase done. I tried to include the test fixes (hence last commit), but from what I see, when the tests are not running one after another then everything is fine. I suppose RPC node needs to process transactions from the previous iteration of testing, so the next one doesn't fail

[thetheveloper]

Should be fine now. Latest base is in place @tcoratger

[adrienlacombe]

@tcoratger @xJonathanLEI anything else needed? thanks!

[tcoratger]

@tcoratger @xJonathanLEI anything else needed? thanks!

For me this is ok to merge but as the PR is quite big and important I would appreciate another review from @xJonathanLEI if possible?

[xJonathanLEI]

Squashed and rebased.

[adrienlacombe]

gm @xJonathanLEI is this good to be merged? ty

[adrienlacombe]

@tcoratger maybe you can review as well? ty ty

[xJonathanLEI]

While this implementation probably works, I'm really not a fan of adding serde_json::Value to a supposedly neutral trait of Provider. I mean it's probably acceptable to add it to JsonRpcTransport, because as its name suggests, it deals with JSON.

I know this is a bit not very pragmatic - after all, Provider is modelled after the JSON-RPC standard. However, with the current design any Provider user would now have to deal with deserialization... which is far from ideal.

Anyway, I just prefer a design where we don't have to pollute Provider with JSON stuff.

The diffs are also a bit all over the place:

• Why do we have a get_block_with_tx_hashes_batch method? Wouldn't that be covered by send_requests?
• Same goes for JsonRpcRequestParams - this type only covers 2 methods.

Closing this as I'll work on an alternative version. Thanks for working on this.