Run collator election during slot prediction

[JoshOrndorff]

Background

When a Moonbeam collator imports a new relay chain block, it may have an opportunity to author the next parachain block. To determine whether it is eligible according the the Runtime's nimbus configuration (based on parachain staking in our case), the collator calls into the runtime to check whether its nimbus id will be selected in the next block.

In Substrate, runtime API calls are made against the ending state of the previous block. When preparing to author the first block in the new round this does not work because the active collator set may change in the next block.

What does this PR do?

In order to accurately predict eligibility, we need to run the election results prior to predicting. This PR adds the minimal amount of logic from parachain staking's on_initialize function needed to do the prediction accurately.

What important points reviewers should know?

Original conversation in (private) slack channel https://purestake.slack.com/archives/C01ACCURYRZ/p1629120510363600

One concern I initially had about running the election during prediction was that the election would be too heavy. Howver, unlike phragmen elections, our elections are just a matter of sorting a list and then taking its prefix. And in the future we may not even need to sort the list. So this concern may not be valid.

Prior to updating our dependencies to the polkadot-v0.9.8 series, we had the same behaviour that this PR introduces. At that time every runtime api call began with full initialization of every pallet. That changed in paritytech/substrate#8953 The election prediction logic being re-introduced here is considerably lighter than prior to that PR, and we never noticed performance problems at that time.

What alternative implementations were considered?

#725 also solves this problem, but in a much different way. That PR runs the staking election onchain ahead of time.

This PR is less invasive in terms of changing parachain staking, but that may be a useful feature beyond the scope of this problem.

Is anything left for followups

To make this work I had to make a function in parachain staking public. That is not the safest interface. If we like this approach long term, it may be helpful to modify parachain staking's interface to expose a safer public function for this purpose. But it isn't really that bad as it is.

[JoshOrndorff]

Based on burn-in testing with @purestakeoskar on Moonbase Alpha, I believe this PR is tested and ready to be merged.