Split RPCs into a separate crate

[jsdw]

Create a new crate, subxt-rpcs. This crate exposes:

• methods: legacy and chainHead RPCs are exposed (the same set that were available in subxt), and archive methods will be added here later.
• client: a set of clients are exposed: jsonrpsee, reconnecting-rpc-client, unstable-light-client and mock-rpc-client. Any of these can be used to call the methods. Subxt makes use of each of these.

Basically, we get all of the low level network communication/serialization/deserialization/typing handled for us, without any of the additional abstraction that Subxt places on top. Useful if you want to interact directly with the RPCs but don't want any other features provided by Subxt.

[niklasad1]

The question is whether we shall support more rpc methods such as rpc v2 archieve and similar.

I think no, but we could open an issue for it

[jsdw]

I def think we should add support for archive methods, but ended up deciding to leave it for a separate PR

[niklasad1]

This error variant Rejected was removed/cleanup in this by why "..".

Is the DisconnectedWillReconnect converted to a Client error?

[jsdw]

Oh I just used ".." because it's just test code so not really relevant what the reason text is :)

IIRC The RequestRejected error was only ever used in the case that we got a LimitReached response back from the chainHead RPCs, so I renamed it to be LimitReached as it's a bit of a special case error (ie the MethodResponse::LimitReached we get back isn't an error from the API, but we want to turn it into one in Subxt).

In this particular test I just think that any error was good enough to show that after an error the stream returns None

[niklasad1]

again, rejected was refactored to a client error instead?

when are we using LimitReached now? Only for the chainhead backend?

[jsdw]

Yeah; LimitReached is an error that signals that the chainHead backend returned the non-error response LimitReached, which we treat as an error in Subxt and so turn into one.

I don't remember explicitly changing any errors from Rejected to ClientError (should be form Rejected to LimitReached), but in some of these tests it doesn't matter, so I might have opted for an error that didn't have any "special" retry consequences!

[niklasad1]

Technically, we should ensure that response_started was sent "before" the messages in the tokio::spawn above.

if the tests passes it's not a big deal but you use a oneshot for that here.

[jsdw]

Actually, I don't mind if some data comes back before the "response started" because, owing to races, there's a chance that could happen in real life too, so this checks that the client is ready to receive such messages before the response comes back (which I think we do; we subscribe before making the call to buffer any responses)

[niklasad1]

Looks great so far, it's definitely a nice cleanup of the error handling.

I got tired now and I'll finish the review tomorrow.