fix: pending runtime api for pending state

[koushiro]

The original design of pending runtime API was wrong, and the later fix about using the aura consensus were also problematic.

See #1123 (comment) for more details

Close #1149

[koushiro]

cc @tgmichel
I'll cherry-pick this PR to the master branch later, but need to update the master branch to minimize the diff with polkadot-v1.0.0 branch (because some backport commits have not been merged into the master branch before).

[boundless-forest]

I am curious why the CI does not report this issue in the prs easier merged.

[koushiro]

I am curious why the CI does not report this issue in the prs easier merged.

If CI reports error, then the previous wrong implementation obviously cannot be merged into the master branch. What you should care about is why the original implementation and later fix are wrong.

The original implementation only considered manual-seal consensus in integration testing, but did not take into account the aura consensus in the production environment, resulting in a panic in the aura consensus.

And the author of later fix PR maybe do not understand the mechanism of the runtime api and aura consensus, I don't know why this fix PR can be merged into master branch :(

[sorpaas]

Usually we shouldn't add breaking changes in release branch, but in this case since it was simply broken let's just fix that this way.

[librelois]

@koushiro @sorpaas We have a problem with the new implementation of pending state, the new closure pending_create_inherent_data_providers doesn't seem to allow custom data to be injected as an argument.
And we need to inject a relay_parent_hash.

Unfortunately, we can't just provide an implementation of pending_create_inherent_data_providers that retrieve the relay_parent_hash from the best block, because we have a check (CheckAssociatedRelayNumber) that requires the relay block number to be strictly incremented.

To solve this problem, we need a way of knowing that we're in the "pending" context and apply a different check in this context (allow same relay number).
The only idea I've got so far is to create a new runtime api pending_apply_extrinsic then use this new runtime api instead of apply_extrinsic to let the runtime know that we're in the "pending" context.

What do you think? Do you see a better solution?