Update parachain-staking M1

[4meta5]

CC @crystalin @dtyoo

Summary and Justification

A recent audit by Security Research Labs of parachain-staking pallet revealed critical vulnerabilities and communicated feature prioritization necessary to ensure the parachain-staking pallet is safe for general usage.

This PR updates parachain-staking.md (#389) Milestone 1: Improve Parachain-Staking Pallet to include the prioritized features.

1. Patch both critical vulnerabilities reported by SR labs.

SR labs reported two critical vulnerabilities in parachain-staking: (i) total locked balance was not updated in {collator, nominator}_bond_more leading to a potential underflow error (which could trigger excessive issuance) (ii) bounded number of nominations per collator allowed any account to fill the slots with the minimum nomination thereby preventing higher nominations. Both vulnerabilities have been patched and integrated into live deployments (Moonriver) via runtime upgrades.

2. Add optional parachain bond configuration that enables reserving a portion of inflation for future parachain bonds.

Moonbeam reserves 30% of inflation for future parachain bond(s). To support this functionality, parachain-staking added the storage item ParachainBondConfig. This storage item is updatable by the root origin; it configures the percent (30%) of inflation reserved as well as the AccountId which receives the reserved funds. This feature is convenient for parachains in the Polkadot ecosystem, all of which must pay rent to the relay chain by locking funds in the parachain bond.

This PR removes two tasks associated with the milestone 1 in favor of prioritizing the features listed directly above.

1. Add constraint of max 1 nomination per AccountId and integrate frame/pallet-proxy to maintain support for multiple nominations.

Benchmarking on the nominate runtime method generates a weight function which charges transaction fees in proportion to the number of existing nominations. This design was not intentional (it was generated by benchmarks) but it does mean there is an explicit disincentive to make additional nominations from one account.
Moreover, the frame/pallet-proxy is already configured in the Moonbeam runtimes so the functionality to use it already exists. Adding the constraint of max 1 nomination per AccountId is not necessary with an existing disincentive to make additional nominations.

2. There is no slashing in the current implementation. We will add slashing for equivocation (signing two different blocks at the same height). This requires first adding equivocation detection to frame/aura.

Equivocation is not a slashable offence for collators if the two blocks produced at the same height have different relay chain parents -- cumulus issue #492. We will revisit slashing in a future upgrade because it is necessary to hold bad actors accountable. Even so, our current efforts are focused on improving the stability of the core of parachain-staking.

Our team was able to quickly patch the vulnerabilities reported by SR labs and runtime upgrade all live networks (including Moonriver) with the fixes. On all live testnets, parachain-staking has demonstrated consistent functionality to (1) select the active set of eligible block producers (2) reward block authors and (3) enable nominators and collators to participate in inflationary rewards.