Create voting_period and seal off vote data

[djrtwo]

Issue

Note: this update will be paired with a corresponding update to EIP 1011.

There are issues with the assumed one-way independence between votes and normal block transactions. We aim to create a two-way independence between votes and normal block txs to ensure paralellizability of vote txs and to remove the ordering constraint on vote txs (votes will no longer have to be at the end of the block).

We do this by

• creating a voting_period in which only votes can modify state.
• hiding the state that votes are modifying and only update publicly readable state after the voting period, during initialize_epoch.

The new hidden vote related vars will be readable via ENTRY_ADDRESS so that they are still accessible off chain to interested parties such as Validators.

voting_period degrades UX for validator clients due to the requirement of timing non-voting actions to fall not in_voting_period, but this is a necessary trade off to achieve vote parallelization.

Proposed Implementation

• Add contract var VOTE_START_BLOCK (greater than 0 and less than EPOCH_LENGTH, suggested 13)
• Add contract var ENTRY_ADDRESS (suggested 0x1)
• Create a public method in_voting_period() that uses VOTE_START_BLOCK
• Add assertion to state-modifying methods other than vote -- assert not self.in_voting_period()
• Add assertion to vote -- assert self.in_voting_period()
• Modify vote so that it is modifying a hidden set of variables related to the current epoch. These variables can only be read by ENTRY_ADDRESS.
• initialize_epoch updates public vars from the hidden set of vote variables. Including paying vote inclusion rewards to miners
• move validators__deposit to a separate map. This map is only readable outside of the voting period OR any time by ENTRY_ADDRESS

in_voting_period() is something like the following:

def in_voting_period() -> bool:
    return block.number % self.EPOCH_LENGTH >= self.VOTE_START_BLOCK

[djrtwo]

This should solve #117