Disallow single Eth1 block in two voting periods

[mcdee]

The definition of a candidate block in is_candidate_block allows for an Eth1 block whose timestamp is exactly aligned with the start of an Eth1 voting period to be considered in two voting periods.

This patch ensures that such a block can only be included as a candidate for a single voting period.

[hwwhww]

I think it doesn't help for "a block can only be included as a candidate for a single voting period." since ETH1 block time is not matching ETH2 period, so ETH1_FOLLOW_DISTANCE * SECONDS_PER_ETH1_BLOCK != EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH * SECONDS_PER_SLOT.

Illustration:

overlapping time = ~0.6 hour

But it's interesting to think more about how to mitigate the overlapping!

[djrtwo]

yeah, you're right @hwwhww. What we probably want to ensure is that we don't consider any blocks that are older than state.eth1data. Because Eth1Data doesn't have a timestamp, we can use deposit_count as a proxy.

maybe the following:

votes_to_consider = [
    get_eth1_data(block) for block in eth1_chain if (
        is_candidate_block(block, period_start)
        and get_eth1_data(block).deposit_count > state.eth1data.deposit_count
]

[djrtwo]

close in favor of #1836