Election Trait and Configurable Staking

[kianenigma]

currently, staking is very much hard-coded to use sp-phragmen. It won't be trivial and will need a lot of code to be moved around, but ideally we should have a staking module which is independent of its underlying election and can be configured. Perhaps some chains would need simpler election mechanisms.

The election trait should contain the bare minimum API, and should represent a multi-winner election:
An elect function will always

• accepts a list of candidates (without any stake -- self votes need to be dealt with at call site), a list of voters zipped with their stakes and targets, and a count to elect (this implies deprecating the minimum_validaotr_count).
• return a list of winners, and each nominator's stake distribution as a configurable generic PerThing.

This is coming from the current phragmen definition, but as far as I can think of, any sane election should provide at least these two pieces of information as output.

Staking will henceforth only work with Type Election: MultiWinnerElection<...>.

Some of the functionality that will probably be common between phragmen and any other election method that implements the above trait should be moved to primitives/election. This can be all the functions that work around the SupportMap data structure and all the helper functions.

Finally, the elect implementation with its tests can be decoupled from all the above and moved into a separate repo. No more sp-phrgamen will exist within substrate; just some Trait MultiWinnerElection and some helpers around it.

There are lots points of ambiguity here; for example where would the equalise() fit into this model. Before articulating more, I'd like some initial feedback if the main objective:

ideally we should have a staking module which is independent of its underlying election and can be configured

is even worth pursuing.

[kianenigma]

I will close this since it has been rephrased in #6242 and the details explained there are much more realistic.