🐳 feat(protocol): alpha-4 with staking-based tokenomics

[adaki2004]

// New concept TLDR:
// 2 main data 'registry':
// - TopProver array: we keep track of the top32. We need an array because we need to iterate over
// - ExitingProver mapping: each and every prover who is either exiting or kicked out (by someone staking more) is
// here until they are not withdraw the funds (with exit())

// NOTE:
// - signalling an exit if you are a prover can be done via stake(totalAMount = 0)
// - modifying existing parameters also done via stake (see comments there)
// - there are mechanisms in the stake() code to handle scenarios like:
//     A: Bob is the least staker. Alice comes in and stakes more than Bob and Carol.
//     Now Bob forced to leave and not within the ExitingProvers. He realizes it and
//     tries to re-stake. Now he stakes more than Carol, so Carol is gone, but Bob can
//     re-use his funds currently in the 'staking queue'. So basically he is out of the
//     exiting queue.
//
//     B: Almost same situation as above, except that when Bob is leaving (force leaving)
//     Carol decided to leave as well, so she is not in the topProver array anymore. It means
//     Bob could come back with his stake (currenlty in the exit 'queue') or even less than that
//     amount since Carol left, there is 1 "free space". So he could decide to re-stake less than
//     his amount in the current exit 'queue', so technically he still have some left in the exit queue
//     while also being a topProver in the same time!

[cyberhorsey]

i think we can remove systemProofCooldownPeriod from config now, right?

[adaki2004]

@dantaik @Brechtpd
Good news is that we have a working PoC initial implementation of the PoS system.
Covered with tests the following behaviors:

• Prover assignment distribution indeed correlates with the staked amount
• Code (protocol) can handle if staker list is: full, empty, 1 or just couple of provers are staking
• Only provers (stakers) can prove their blocks within the proof time window, and everyone else otherwise
• Slashing works
• Provers could exit and will not get blocks assigned afterwards, and if another (highest) prover joins the assign prover distribution (weighting) works well

IMO this is a good PoC/ working solution so we might want to ask @davidtaikocha and @cyberhorsey to proceed with the client so we will have something in our hand by end of this week.

The less good news on the other hand is the gas consumption, comparison.

The current alpha3 gas consumption as a benchmark:

This version (with full list (32) of stakers/provers):

This version (with 5 stakers/provers):

Currently it raises 3-4x the proposeBlock() consumption, and cca 2x the proveBlock().

@dantaik I guess there is room for some optimization, but would be great if you try it, to reserve the working mechanics/behavior of the code so we dont have to adjust the tests.

I'll try to reach the (as close as possible) same behavior with the Brecht's proposed solution (tho the client interactions will differ a bit) but will give it a shot!