Pre-generate runtime API clients to use on light nodes

[svyatonik]

We may want to (remotely) call some runtime methods from the light nodes. Currently, the call must be manually encoded like in this example:

fetcher.remote_call(RemoteCallRequest {
	block: best_hash,
	header: best_header,
	method: "AccountNonceApi_account_nonce".into(),
	call_data: account.encode(),
	retry_count: None,
})

I'm suggesting to extend decl_runtime_apis! macro (or add some additional macro) that will generate structure to be used on light nodes for calling some (we do not need it for everything) runtime methods. It could be something like that for declaring (mind the : Light):

decl_runtime_apis! {
	pub trait TaggedTransactionQueue: Light {
		fn validate_transaction(tx: <Block as BlockT>::Extrinsic) -> TransactionValidity;
	}
}

The example usage of generated client:

LightTaggedTransactionQueue::at_header(fetcher, hash, header)
	.validate_transaction(transaction)

[bkchr]

Why not just implement CallRuntimeAt for something that sends the data to a full node and sends back the result?
Then you can just use any runtime api without any change.

[svyatonik]

Thanks, that is probably be a better option - haven't thought about implementations details yet. The main concern is that currently we need to hardcode method name + manually encode method arguments + manually decode method return.

[bkchr]

CallRuntimeAt already gets the function name as &str and the encoded parameters :)

[svyatonik]

Yes I know, I'm describing the current situation with calling runtime methods from light client. If it'll be possible, we'll use CallRuntimeAt.

[bkchr]

Yeah understood this. If there is anything where we can improve the runtime api, just write me :)

But don't you already have the special call_executor implementation for light clients. Shouldn't that be usable as well?

[svyatonik]

OK, thanks.

I've removed remote calls support from light' CallExecutor recently to: (1) avoid blocking io threads (2) avoid unplanned (and unpredictable) runtime calls from light client. So now whenever we need to call into runtime from the light client, we need to explicitly use Fetcher.

[EmmanuellNorbertTulbure]

Is this still relevant @svyatonik ? Asking to know if I should migrate it or not.