Refactor StarknetProvider and StarknetRequest

[franciszekjob]

Describe your changes

This PR focuses on refactoring StarknetProvider, StarknetRequest and related structs/protocols for sending RPC calls.

Introduced changes:

• Move logic responsible for building requests form StarknetProvider to StarknetRequest which is now just a container for a RPC call.
• Remove send method from StarknetRequest.
• Add send method to StarknetProvider responsible for sending single/multiple RPC calls.

Linked issues

Closes #215

Breaking changes

• This issue contains breaking changes
• Move methods responsible for building RPC calls from StarknetProvider to StarknetRequest.
• Remove send method from StarknetRequest - use added send in StarknetProvider to send RPC calls
• Add provider param in estimateFeeV1 and estimateFeeV3 in StarknetAccountProtocol; Update following methods in StarknetAccount

[franciszekjob]

note: provider needs to be changed to public, because it's added in StarknetAccountProtocol here.

[DelevoXDG]

Hmmm, I understand that it's used in the extensions, but I wonder if provider should be included in the account protocol, as it's making the protocol reliant on component that is more implementation-specific (rpc communication), therefore making the account protocol less abstract

[franciszekjob]

as it's making the protocol reliant on component that is more implementation-specific (rpc communication), therefore making the account protocol less abstract

I agree 👍 Just one remark - not adding provider in StarknetAccountProtocol enforces to add extra provider param in estimateFeeV1 and estimateFeeV3. Hope this one is not too cumbersome while using these methods.

Wdyt guys @DelevoXDG @mluisbrown?

[mluisbrown]

We would only need to pass in the provider in the estimate methods that don't take nonce param, right? That seems ok to me.

[mluisbrown]

We would keep the provider property in StarknetAccount though, right? It doesn't need to be in the protocol but it needs to be a public property in StarknetAccount.

[franciszekjob]

Ofc, we will keep it in StarknetAccount . I added provider param to estimateFeeV1/3 which don't have nonce param 👍 .

[DelevoXDG]

Can't we just make the methods abstract and define them in StarknetAccount instead?

[franciszekjob]

note: Deleting as it's not used anymore.

[franciszekjob]

note: As discussed with Argent team - now we want RPC calls to be static methods.

[THenry14]

@DelevoXDG please also take a look

[mluisbrown]

Please see my comment about having the static request methods in an extension of the generic StarknetRequest type, which makes using them more cumbersome than necessary.

[mluisbrown]

All looks great now. Integrated into Argent and also ran our tests against it and all good.
Nice job 👍