[EPM] Adds on-chain update mechanism for untrusted minimum score

[gpestana]

Currently, we calculate and update the MinimumUntrustedScore manually by calling Call::set_untrusted_min_score. Historically, the MinimumUntrustedScore value has calculated by fetching the last 30 election scores and halving their average. This approach requires developers to keep an eye on how the election scores are evolving with time and updating the MinimumUnstrustedScore requires considerable overhead with governance proposals and manual work. In addition to that, values that are lagging behind the previous may open attack vectors for attacks.

This PR implements an on-chain mechanism that dynamically updates MinimumUntrustedScore based on a rolling average of previous N election scores.

This PR adds a new storage item (MinimumUntrustedScoreAvg) which is updated every time a new election finalises successfully. If at least MinimumUntrustedScoreUpdateInterval elections (eras) have passed since the last update, the MinimumUntrustedScore is updated with the latest MinimumUntrustedScoreAvg. The final set value of the untrusted minimum score is a fraction (MinimumUntrustedScoreMargin) of the calculated rolling average to give a safety margin for the subsequent elections. The MinimumUntrustedScoreBackstop enforces a lower bound on the minimum untrusted score set.

When a new MinimumUntrustedScoreUpdateInterval is set through a runtime upgrade while a rolling average is being calculated, we detect that and reset the current rolling average. In addition, when a new minimum untrusted score is set through calling Call::set_minimum_untrusted_score, the current average is also reset.

New Dispatchables

• set_minimum_untrusted_score_backstop(maybe_score_backstop): sets the MinimumUntrustedScore; can be called by T::ForceOrigin.

New Events

• NewMinimumUntrustedScore: emitted when a new minimum untrusted score is set through the on-chain update mechanism.

Task list

• [x] improve test coverage
• [x] companion PR
• [x] update bin/node/runtime

polkadot companion: https://github.com/paritytech/polkadot/pull/7357

---

Closes https://github.com/paritytech/polkadot-sdk/issues/456 More info https://hackmd.io/IwJiYgMwRKer0e7khbLhUQ

[gpestana]

bot rebase

[paritytech-processbot[bot]]

Rebased

[AlistairStewart]

I'm still worried about the possibility of black swan events making the best possible score below the minimum set here. Particularly worrying is one where most of the validator set are chilled for some reason and leaving us with a small set. This will cause the score of possible solutions to drop a lot, because any solution would have to include a lot of waiting validators. It still might be better for the chain to expand the set and include a few less backed validators, because then nominators are incentived to help the recovery by backing the now highly profitable less backed validators or waiting validators who now have a lower barrier to entry.

With the assurance that we can still lower this by governance in case such an event happens, this PR is a strict improvement on what came before.