Miscellaneous beacon chain changes—take 3

[JustinDrake]

(See #128 and #218 for takes 1 and 2.)

• 1. Pull out validator balances: Performance optimisation whereby the validator balances are segregated from the validator_registry. (The balances of active validators change every epoch, whereas the rest of the registry changes infrequently.)
• 2. Historical justification bitfield: Merge previous_justified_slot, justified_slot, justification_bitfield and finalized_slot into a bitfield that grows by one bit every epoch. (Cleaner, more flexible.)
• 3. Latest RANDAO mixes: See Keep latest 2^n RANDAO mixes in the state #295.
• 4. Placeholders: Add placeholders for proofs of custody and VDFs. See Add proofs of custody #145 and c8efdc7.
• 5. Light-client friendly shuffles: See Possible alternative numer-theoretic shuffling algorithm #323. Decision: Rework the shuffle function to be more local and put a notice explaining that the shuffle function may change.
• 6. Delayed exits: Add a new constant MAX_SEED_LOOKAHEAD (complementing MIN_SEED_LOOKAHEAD) and keep forced ejections in the validator registry at least MAX_SEED_LOOKAHEAD for the purposes of shuffling. This addresses a shuffle grinding vulnerability with forced ejections. See Delay exits with penalty #350.
• 7. Timestamped activations and exits: Allows to compute the validator registry in the past, and remove shard_committees_at_slots and persistent_committee_reassignments.
• 8. More granular partial slashing: Update latest_penalized_exit_balances on an epoch-by-epoch basis and flush old values.
• 9. Fair partial slashing: Compute partial slashing a fixed amount of time after an exit.
• 10. Remove registry delta chain: Remove validator_registry_delta_chain_tip in favour of batched_block_roots. (Can be removed when adding Mitigating attacks on light clients #403 functionality)

[vbuterin]

For (2) I don't think it's nearly that simple. state.finalized_slot being updated depends not just on the pattern of justified slots but also on what the state.previous_justified_slot was at the time it was updated. So I don't think we can get rid of finalized_slot. We also need state.previous_justified_slot and state.justified_slot to remember what was the source that messages were supposed to be using in the previous two epochs, and that's not something that can necessarily be figured out from a justification bitfield because the justification bitfield might change but the justification sources should not change.

[vbuterin]

Light-client friendly shuffles: See #323.

I think we should not consider this a milestone for the spec release at this point. Would rather calmly take a couple of months to talk with academics about what the best shuffling algo for our use case is, and we can swap it in later.