Update previous epoch calculation

[ralexstokes]

What was wrong?

Fixes #382.

Replaces #398.

How was it fixed?

Started rebasing #398 and realized we want to handle some of the tests differently.

This has the same content but keeps some of the tests... after further inspection I think what I had in #398 was actually weakening the test coverage.

Cute Animal Picture

[ralexstokes]

@ChihChengLiang @hwwhww @NIC619 given that you reviewed the other PR, i'll tag you here.

like stated above, i started rebasing and realized we want to handle some of the testing in a better way.

the one thing i could call special attention to is test_justification_without_mock. it seems like it should yield a bitfield 0b0 unless we provide attestations. and it doesn't seem like we will get 0b11 until we run through two epoch processings. so i think that the prior implementation was incorrect and has now been fixed (although is not testing the scenario where we do in fact hit 0b11) and that there was a bug in the previous implementation of _current_previous_epochs_justifiable. if i'm wrong, then there is a bug in the new _is_epoch_justifiable and will happily track it down so let me know :)

thanks!

[ChihChengLiang]

@ralexstokes Feel free to fix them, those functions are implemented before v0.2.0.

Prior to this PR, previous epoch and current epoch is 0 on the genesis, that's the very reason why test_justification_without_mock is getting 0b11.

_current_previous_epochs_justifiable is also an awkward move to address the behavior of previous epoch and current epoch near genesis. As the consistent behavior introduced, it is safe to nuke _current_previous_epochs_justifiable and replace it with _is_epoch_justifiable.

[ralexstokes]

@ChihChengLiang great -- went ahead and did that! just to confirm, we do want this w/ the latest implementation correct? https://github.com/ethereum/trinity/pull/469/files#diff-9ffda674671b43bc2ac2193ad772c6a5R319

this is my understanding but we want to be extra careful about justifying the correct stuff :)

[NIC619]

Probably also need @ChihChengLiang 's review on this but the refactoring makes a lot of sense! 👍

[ChihChengLiang]

Great work! Only leave some nitpick here. Justification and finalization look good to me, their core logic did not change much in the spec and the test cases are still valid.