Add beacon chain helper functions

[hwwhww]

What is wrong?

Part of #930

• The helper functions in beacon_chain are all pure functions with a config: Dict[string, Any] parameter.
• Some helpers functions are like ~90% similar to the spec as a reference implementation. But to fit Py-EVM paradigm, we may have to refactor a lot.

How can it be fixed

It may take multiple steps:

1. Move all pure functions to eth/beacon/helpers.py - I have a commit here: hwwhww@5724a7a
2. Introduce eth.beacon.db.chain.BeaconChainDB
3. Introduce eth.beacon.state_machines.base.BaseStateMachine(Configurable)
4. Introduce eth.beacon.chains.chain.BeaconChain
5. Tear down helpers: move some of them to eth.beacon.state_machine.base.BaseStateMachine or being static functions / properties in eth.beacon.types.* classes.

cc @djrtwo @pipermerriam

[pipermerriam]

• The config object can probably be updated to be a typing.NamedTuple for stronger type safety.
• Modifying the helper functions to be non mutative looks like something that will go relatively quickly.
• Writing tests for all of these is probably the largest task (take care to not waste time writing exhaustive tests on things that are likely to change).

[pipermerriam]

Also, ideally, rather than passing a config object around through these various helper functions, it would probably be better to just explicitly pass the specific configuration values as individual parameters.

[djrtwo]

config in this context can be seen as "global" parameters for the particular instantiation of the chain/fork. These would be constants probably defined in beacon.state_machine.forks.fork_name.constants, right?

edit: and agreed on passing individual config params as needed

[pipermerriam]

On second thought, I'm curious if we can get away with the same pattern that the existing code uses, placing these in a constants file and importing them as needed. For parameters that end up changing for various forks, we can place them in eth.beacon.forks.fork_name.constants (as danny suggested)

[hwwhww]

Yes, that makes sense. We will have Configurable StateMachine to handle these chain configurations.

[djrtwo]

Yeah, I agree the import is the way to go on these

[hwwhww]

closed via #1341 and #1381