add proposer index to BeaconBlock

[djrtwo]

Addresses #1601

• add proposer_index to BeaconBlock and BeaconBlockHeader
• remove proposer_index from ProposerSlashing and instead assert that both headers have same proposer index
• add and modify tests

---

Comment from @protolambda below copied here for visibility

LGTM, happy to see this! It will make cases that trust block-roots, but are unaware of the state, aware of proposers. This is good for tooling/bridges/etc.

Note for implementers though: careful, don't trust blocks blindly, follow spec and verify the proposer index.

[protolambda]

Did an initial pass and it looks good. It's a substantial change however, so I like to do a second pass, check if there are more cases where we need to change things. And think about edge-cases like the genesis latest-header proposer index.

[djrtwo]

Sounds good. Added a couple of additional sanity block tests to cover the combinations on how the index might be messed up

[hwwhww]

def process_randao(state: BeaconState, body: BeaconBlockBody) -> None:
    epoch = get_current_epoch(state)
    # Verify RANDAO reveal
    proposer = state.validators[get_beacon_proposer_index(state)]
    ...

could be refactored to

def process_randao(state: BeaconState, block: BeaconBlock) -> None:
    epoch = get_current_epoch(state)
    # Verify RANDAO reveal
    proposer = block.proposer_index
    randao_reveal = block.body.randao_reveal
    ...

[djrtwo]

@hwwhww I decided to make the changes minimally invasive and to only check that the specified proposer index in the block matches the expected in state once process_block_header. Otherwise to keep everything to same.

One place that could also be refactored is process_attestation, but this would involve changing the function signature.

Since proposer shuffling lookup will almost certainly be memoized, this is safe and doesn't really add a cost to processing

[protolambda]

LGTM, happy to see this! It will make cases that trust block-roots, but are unaware of the state, aware of proposers. This is good for tooling/bridges/etc.

Note for implementers though: careful, don't trust blocks blindly, follow spec and verify the proposer index.

[hwwhww]

Agreed with minimal changes here and the clients can still optimize it if they want.
LGTM!