add rpc_client to Backend trait

[yjhmelody]

User maybe need to add custom jsonrpc request so the internal rpc client need to be accessed.

Or maybe just return RpcClient is enough?

[lexnv]

This mostly looks good to me!

A minor nit wrt exploding the client on the RPC methods directly (LegacyRpcMethods and UnstableRpcMethods).

Another approach for users would be keeping a clone of the inner RPC client:

let rpc_client = ..;
// Clone the client here.
let unstable_backend(rpc_client.clone);

This PR should remove the need for any cloning. Thanks for contributing! 🙏

[lexnv]

I'm not sure this would fit well with the Backend trait.

At the moment we are exposing two implementations and both fetch using jsonrpsee from a running node some details:

• either from the legacy RPC
• or from the unstable RPC backend

However, I believe there's nothing that should stop users from providing a completely offline experience using subxt:

• using a raw static database
• feeding data from some third party which may not have the concept of rpc methods, or just from some in memory socket that communicates with a daemon process

And because of that, exposing the rpc_client here feels like exposing an inner detail of some type of implementations, while possibly restricting others.

I believe the same could be achieved if this method would be moved instead on UnstableBackend and LegacyBackend, since it feels more inline with their inner details.

@niklasad1 @jsdw what do you think?

[niklasad1]

I don't remember the reason why James made it an implementation detail of the Backend but I think it makes the rpc API in subxt less leaky and easier for us to break stuff internally.

However, it's still possible to access the rpc client but in a slightly different manner

After this change users have to do:

   let rpc_client = RpcClient::from_url("ws://localhost").await.unwrap();
   let subxt_rpc = LegacyBackend(rpc.clone());

  // rpc_client can be used make arbitrary rpc calls.
  // subxt_rpc only provides the APIs provided by the backend.

Thus, it's by design and my cents is to not accept this PR but let's wait for @jsdw to be back from
vacation and give his thoughts on this.

[jsdw]

It's be design not to expose an RPC client from the Backend trait yeah.

One of the main points of the Backend trait was to abstract away any details about specific RPC calls, so that we can have a legacy and "new" backend and be certain that eg no "stray" RPC calls to old APIs are used in the new backend impl. exposing an "rpc_client()" would allow higher level APIs to break this and call methods that they shouldn't.

Another more esoteric reason is just that the Backend trait as it stands is designed to provide exactly the interface needed for the higher level Subxt APIs and no more. This means that it would be possible to have a backend which doesn't care about RPCs at all (and eg uses some new binary interface or whatever in the future).

[jsdw]

Closing as we won't expose the RPC methods through the Backend trait in this way. We are adding an example though to make it clearer how to use RPC calls with Subxt (see #1279)