Add proposer_id to BeaconBlock

[djrtwo]

I didn't realize #1339 had been closed! Creating this issue for some fresh eyes. This is something I'd definitely like to revisit and maybe have auditors look at this month.

See #1339 for the original description of the issue.

The tldr is that without a proposer_id and a way for a quick signature verification on an incoming block, an attacker can create blocks with some amount of skip slots that require database look ups and state transitions to even validate the proposer signature. In the current case, that attacker doesn't even need to be in the validator set.

By adding the proposer_id we at least reduce the set that can craft such blocks to the validators and limit them to a 1 per slot allowance (due to gossip conditions and slashing conditions). This rate limit combined with peer scoring (and dropping!) at least begins to bound this problem.

[protolambda]

You have my support for this change. And prefer proposer_index over proposer_id to be more consistent with the other places where we use validator indices.

[terencechain]

+1 on this change. This will result in better client code

[protolambda]

Closing this issue, the proposer id (index) has been introduced in #1626, to be featured in upcoming v0.11.0 release.