Functional replacement for genesis state access

[holgerd77]

I did some manual testing of the TypeScript-updated library by injecting a packed library into the VM node_modules folder and realized that the current static genesis state access method is broken along with the distribution reorg.

After tinkering around a bit I came to the conclusion that this cannot be properly recreated with the switch to ES6 import syntax and we have to do a breaking change here and then release the updated library as v1.0.0 (which should be ok).

This PR introduces two new methods genesisStateById, genesisStateByName which can be directly imported and used for access the genesis state dictionaries. It also updates README and docs and adds two new test cases.

[coveralls]

Coverage increased (+0.4%) to 96.327% when pulling 832dfb8 on fix-genesis-states-import into 41a5413 on master.

[s1na]

@holgerd77 Great that this was found out! The PR looks good. I just didn't quite understand what the issue with ES6 imports was? Is the reason a major version bump required the fact that the path to genesisStates is different (has additional dist)?

[holgerd77]

Yes, it has additional dist in the path. On top it is not possible to define constants with default export, so on import this gets wrapped in another genesisStates dict key and access would be something like:

const genesisStates = require('./dist/genesisStates')
genesisStates['genesisStates']['mainnet']

If you are ok with it can you approve or alternatively request additional changes, but directly through the review functionality?

[s1na]

Thanks for explaining, using function to get the data is probably better anyway, as even if the underlying data changes it'd be possible to keep the same interface.

In that case, the other data types (chains and hardforks) should be similar, no? or is this PR only for genesisStates?

[holgerd77]

No, this PR is only for genesisStates which are accessed separately due to performance and memory reasons. Access to hardfork and chain parameters is done exclusively through the API as stated in the documentation.

[s1na]

@holgerd77 Ah, sorry I wasn't aware of the difference. I think I should get to know the libraries better before reviews 😅

[holgerd77]

Perfectly fine, better to ask some questions too much than too few, especially on reviews.

And beyond, a) how things are currently done and b) if things make sense are two totally different things. 😄