Add WeightToFee and LengthToFee impls to transaction-payment Runtime API

[notlesh]

This PR makes a runtime's WeightToFee and LengthToFee impls available via runtime API. The rationale for this is that these are now opaque functions which are not directly available in any way outside of a runtime.

Specifically, a client cannot take an executed extrinsic from a block and validate each portion of its fees without knowing this information (or making some assumptions). We do this extensively in testing on Moonbeam.

polkadot companion: https://github.com/paritytech/polkadot/pull/6536 cumulus companion: https://github.com/paritytech/cumulus/pull/2073 polkadot-js/api companion: https://github.com/polkadot-js/api/pull/5430

[notlesh]

In trying to test this, I came across something unexpected. With my changes (my Polkadot companion PR plus diener overrides), the transactionPaymentApi and transactionPaymentCallApi both disappear from Developer > Runtime calls -> Calls:

On recent Polkadot master, they both appear as expected:

Any idea what might be causing this?

[notlesh]

Any idea what might be causing this?

I believe this is because the type info is currently hard-coded here: https://github.com/polkadot-js/api/blob/ebb9f055c13d663bf3af5fad5043c5461b2f2b8a/packages/api-augment/src/substrate/runtime.ts#L268

Should I open a companion PR to include this new definition there? CC @jacogr

Are there examples of using either the state_call (I think that's the State::call() RPC) or api.runtime (the later doesn't appear in my testing with @polkadot/api 9.11.2).

[jacogr]

Indeed. At this point they need to be hard-coded/re-defined on the JS API until such time as these appear in the metadata. Once there, it appears on api.call.* (assuming the runtime api version matches - it will decorate based on the version retrieved, if non-matching it only logs that it knows about this API, but doesn't know the version)

Alongside that, I would really encourage you to bump the actual runtime api version (as done here) - because we are hardcoding these each version defines a specific shape (and the types). Unless we bump it all these will also appear decorated for runtimes that don't actually have them but has the same version.

[notlesh]

All companion PRs are now approved (the polkadot-js one approved verbally :) Let me know if there is anything missing :+1:

[ggwpez]

Dont know why the CI is read, lets try rebasing.
PS: Had to informalize your MR description for the PolkadotJS comp since the CI got confused by it.

[ggwpez]

bot merge

[paritytech-processbot[bot]]

Error: "Check reviews" status is not passing for https://github.com/paritytech/polkadot/pull/6536

[ggwpez]

bot merge

[paritytech-processbot[bot]]

Error: "Check reviews" status is not passing for https://github.com/polkadot-js/api/pull/5430

[ggwpez]

bot merge

[michalkucharczyk]

Companions were not merged.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-38/2122/1

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/substrate-developer-newsletter-february-2023-notable-updates-for-frame-devs-new-deep-dives-released-calling-builders-to-apply-to-rfps-and-bounties/2137/1