Introduce new runtime api GetParachainId

[bkchr]

This runtime api should be used to fetch the para id of a runtime and then can be used by the collator to use it. Then we can remove the para id from the chain spec.

(The runtime api should get a better name, the name in the title is only WIP :P)

[kianenigma]

Should the same also be done for decimals and tokenName?

[bkchr]

Should the same also be done for decimals and tokenName?

Could just be put into the metadata?

[Stephenlawrence00]

I think this can be achieved with view functions?

[xlc]

view function is pallet specific thing. runtime API is a runtime specific thing. in this case, runtime API is more sutiable

[iulianbarbu]

Just want to clarify the implementation details since I feel it has been passed around but we've not made it official. I am personally out of context with how runtime APIs should be implemented, and I am curious about the approach.

My understanding so far is that some core runtime apis sit in sp-api, and if we'd want to add a new one, sp-api could be the place. I am thinking we need to implement something similar to Core/Metadata traits, but at the same time, this trait shouldn't be required for all runtime, since parachain-info is something related only to parachains. Therefore, we might need to introduce this new runtime API under cumulus/primitives/core, like we did for CollectCollationInfo/GetCoreSelectorApi, and then implement it with every parachain runtime under cumulus & parachain-template (maybe others).

Can you confirm? cc @skunert @bkchr Also, maybe something is missing above? (e.g. not super sure how we enforce runtime implementors to provide implementations for the needed runtime APIs that are required by parachains/or other runtimes - but maybe this a generic part already checked at some point when building a certain runtime, or maybe we can't enforce it so don't need to worry about it).

[bkchr]

Therefore, we might need to introduce this new runtime API under cumulus/primitives/core, like we did for CollectCollationInfo/GetCoreSelectorApi, and then implement it with every parachain runtime under cumulus & parachain-template (maybe others).

Yes, this should not go into the sp-api crate. This crate is generic over all of the traits. Having metadata there has historical reasons and was a mistake if we look back now :) Putting the new trait into the cumulus/primitives/core sounds good to me.

e.g. not super sure how we enforce runtime implementors to provide implementations for the needed runtime APIs that are required by parachains/or other runtimes - but maybe this a generic part already checked at some point when building a certain runtime, or maybe we can't enforce it so don't need to worry about it

So far, the node would have complained at build time. Generally we should implement checks for required apis and either disable functionality or stop the node if they are not available. This runtime api would fall into the category of stopping the node as without a parachain id we can not do anything :)