Support Runtime Api calls

[haerdib]

So far the api-client does not support runtime api calls. The goal of this issue is to facilitate runtime api calls, in general, and provide helper functions for the runtime api calls of the most commonly used pallets.

Available Runtime Calls: https://polkadot.js.org/docs/polkadot/runtime

Hands on testing: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.dotters.network%2Fkusama#/runtime

Subxt has already put some thoughts into it: see paritytech/subxt#918

Task description

Implement helper functions, just like our rpc calls

substrate-api-client/src/api/rpc_api/frame_system.rs

Lines 73 to 81 in 53be73d

	async fn get_account_info(
	&self,
	address: &Self::AccountId,
	) -> Result<Option<AccountInfo<Self::Index, Self::AccountData>>> {
	let storagekey: StorageKey = self.metadata().storage_map_key::<Self::AccountId>(
	"System",
	"Account",
	address.clone(),
	)?;

that directly access the node api and return the information.

Example code from subxt:

// Create a dynamically runtime API payload that calls the
// `AccountNonceApi_account_nonce` function.
let account = dev::alice().public_key();
let runtime_api_call = subxt::dynamic::runtime_api_call(
    "AccountNonceApi",
    "account_nonce",
    vec![Value::from_bytes(account)],
);

And as reference: here's the call executed by the rpc: https://github.com/paritytech/subxt/blob/9a8fc33f2fe830009011e997773071099101d69b/subxt/src/runtime_api/runtime_types.rs#L43-L106

Already implemented:

• Support for Metadata v15
• Api Metadata (maybe needs adaption)
  

  substrate-api-client/node-api/src/metadata/metadata_types.rs

  Line 48 in 53be73d

  apis: BTreeMap<String, RuntimeApiMetadataInner>,

[haerdib]

Up to date Substrate nodes should already include metadata v15 by default. So this feature should (once the Susbtrate deps are upgraded) already be testable by CI (see PR paritytech/substrate#14481 for more information)

[masapr]

To me it's not clear: do we implement all calls manually? Or do we generate code? If we generate code automatically, do we do this frequently/whenever there are changes in the runtime api call?

[haerdib]

Currently, we are not generating code at all in the api-client. So for now, I'd stick to hard coded helper functions and one function that allows a generic "String" input... or Probably two Strings, as in polkadot.js:

If we want to go more in the direction of code producing code, I believe that should be addressed in a different issue, as it also affects the already implemented RPC calls.