Check if unstable rpc api should be introduced

[haerdib]

Parity has a new (currently unstable) Rpc Api: https://paritytech.github.io/json-rpc-interface-spec/api/chainHead_unstable_body.html

The following should be looked at:

1. When will this be stabilized?
2. Should we already introduce API wrapper functions for this Api, or wait until stabilization?

[haerdib]

According to https://paritytech.github.io/json-rpc-interface-spec/grouping-functions-and-node-capabilities.html:

Unstable functions
No guarantee is offered as to the stability of functions with unstable as their version number. They can disappear, get renamed, change parameters, or change return value without any warning.
For obvious reasons, higher-level applications should not rely on unstable functions. Please open an issue in this repository if some critical feature is missing or is only covered by an unstable function.
The presence of unstable functions in the interface exposed by a JSON-RPC server is not a problem by itself. Not all functions are destined to be stabilized, and it is normal for some functions to remain unstable forever.
Unstable functions are especially useful for core/parachain developers to add debugging utilities to their client implementation. For example, if a developer wants to investigate the list of Grandpa votes, they could introduce a function named grandpa_unstable_votes.
It is expected that all new functions added to this interface go through a testing phase during which they're unstable.

So unstable functions are meant to be used by developers, which is the target group of the api-client. As they may never get stabilized, I believe we should definitely add unstable functions that are of interest already now.

With our CI we will find out when interfaces change and are sure our functions are up to date.

[haerdib]

See https://github.com/paritytech/subxt/tree/54470357165c08fd703373678f38dcc633465cec/subxt/src/backend/unstable for examples

[haerdib]

@masapr what do you think? Should we actually implement these functions?

[masapr]

@haerdib I don't think we should add these. It's more important, that we have a nice example on how our users can make a call we don't provide for them. So that they have the possibility to make these calls, but they are not "encouraged" to do so. Also, let's keep in mind, that any function we add, we also have to maintain. It's not worth it for these type of functions, I think.

[haerdib]

Okay, I totally agree with the idea with the example! Let's do that

[haerdib]

Closing this issue in favor of #728. @masapr please reopen if you disagree.