chainHead: Allow methods to be called from within a single connection context and limit connections

[lexnv]

This PR ensures that the chainHead RPC class can be called only from within the same connection context.

The chainHead methods are now registered as raw methods.

• server: Register raw method with connection ID jsonrpsee#1297
  The concept of raw methods is introduced in jsonrpsee, which is an async method that exposes the connection ID:
  The raw method doesn't have the concept of a blocking method. Previously blocking methods are now spawning a blocking task to handle their blocking (ie DB) access. We spawn the same number of tasks as before, however we do that explicitly.

Another approach would be implementing a RPC middleware that captures and decodes the method parameters:

• rpc-servers: Allow chainHead methods to be called from a single connection #3343
  However, that approach is prone to errors since the methods are hardcoded by name. Performace is affected by the double deserialization that needs to happen to extract the subscription ID we'd like to limit. Once from the middleware, and once from the methods itself.

This PR paves the way to implement the chainHead connection limiter:

• [RPC-Spec-V2] Limit chainHead_unstable_follow subscriptions #1505
  Registering tokens (subscription ID / operation ID) on the RpcConnections could be extended to return an error when the maximum number of operations is reached.

While at it, have added an integration-test to ensure that chainHead methods can be called from within the same connection context.

Before this is merged, a new JsonRPC release should be made to expose the raw-methods:

• Use jsonrpsee from crates io (blocked by: server: Register raw method with connection ID jsonrpsee#1297)

Closes: #3207

cc @paritytech/subxt-team

[niklasad1]

yeah right, spawn_blocking doesn't return a handle for the future that's why you need the extra oneshot channel

[niklasad1]

could also be Arc<Mutex<HashSet<(ConnectionId, SubscriptionId)>>> I guess but perhaps you have plan for it to more generic

[jsdw]

mmm since ConnectionId is just a small u64, I'd just combine to Arc<Mutex<HashSet<(ConnectionId, SubscriptionId)>>> and that would be more efficient & slightly simpler code below, and probably small or no real extra space cost :)

[niklasad1]

I would re-phrase this, I think you are trying to say that each connection has its own state and not that the RPC functionality is limited to a single connection?

This connection state is then used to determine whether a certain call is permitted on a particular connection such as "unstable_storage calls" or something like that...

[lexnv]

I've rephrased the documentation a bit, let me know if it makes more sense now 🙏

[jsdw]

Am I right to assume that we are not worries about subscription IDs and operation IDs colliding at all in our implementation here?

[lexnv]

Yep, IIRC, we'll either use this for chainHead with subscriptions ID only; or for the tx with operation ID only

[jsdw]

Do we ever clear out entries completely when the number goes to 0? Else we might eventually leak memory

[jsdw]

Ah, I guess this is whewre we clean up :)

[jsdw]

Looks good to me; only very small comments in the end :)