more fork-choice fixes

[arnetheduck]

• use target block/epoch to validate attestations
• make addLocalValidators sync
• add current and previous epoch to cache before doing state transition
• update head state using clearance state as a shortcut, when possible
• use blockslot for fork choice balances
• send attestations using epochref cache

[tersec]

Rebase to fix the build: #1389

[arnetheduck]

green now on travis @tersec

[tersec]

It seems like this might create race conditions with other parts of the code perhaps if the local validators aren't yet there?

[arnetheduck]

well, the code is more synchronous now without the await because addlocalvalidators is no longer asynchronous (notably, because it no longer has to schedule anything on the async loop)

[tersec]

Couldn't blocks skip slots here, including the first slot of an epoch?

[arnetheduck]

that's why BlockSlot.parent moves slot-by-slot instead of block by block :)

[tersec]

TRC 2020-07-30 15:09:01+00:00 Updating checkpoint                        topics="fork_choice" tid=6956 file=fork_choice.nim:222 current_slot=2 best=ec48235b:0 current=ec48235b:0 updateAt=None[Epoch]
D:\a\1\s\tests\testutil.nim(80) test_attestation_pool
D:\a\1\s\tests\test_attestation_pool.nim(220) runSuite
D:\a\1\s\beacon_chain\attestation_pool.nim(345) selectHead
D:\a\1\s\beacon_chain\fork_choice\fork_choice.nim(337) find_head
D:\a\1\s\beacon_chain\fork_choice\fork_choice.nim(300) find_head
D:\a\1\s\beacon_chain\fork_choice\fork_choice.nim(414) compute_deltas
D:\a\1\s\vendor\nimbus-build-system\vendor\Nim\lib\system\fatal.nim(49) sysFatal

    Unhandled exception: value out of range: 32000000000 notin -2147483648 .. 2147483647 [RangeError]

On 32-bit Azure

[tersec]

But regardless, it seemed not to notice/care, and moved on to the next test:

D:\a\1\s\vendor\nimbus-build-system\vendor\Nim\lib\system\fatal.nim(49) sysFatal

    Unhandled exception: value out of range: 32000000000 notin -2147483648 .. 2147483647 [RangeError]
[NimScript] exec: nim c --out:./build/test_fixture_ssz_generic_types -r -d:chronicles_log_level=TRACE --verbosity:0 --hints:off -d:chronicles_log_level=TRACE -d:debug -d:disable_libbacktrace tests/official/test_fixture_ssz_generic_types.nim 

[Suite] Official - SSZ generic types
[OK] Testing basic_vector inputs - valid - skipping Vector[uint128, N] and Vector[uint256, N]
Unsupported **size** in type/size combination: array[0,bool]
Unsupported **size** in type/size combination: array[0,uint16]

...

10 longest individual test durations
------------------------------------
  0.44s for Testing containers   inputs - valid - skipping BitsStruct
  0.26s for Testing basic_vector inputs - invalid - skipping Vector[uint128, N] and Vector[uint256, N]
  0.16s for Testing bitlist      inputs - valid
  0.12s for Testing basic_vector inputs - valid - skipping Vector[uint128, N] and Vector[uint256, N]
  0.06s for Testing uints        inputs - valid - skipping uint128 and uint256
  0.03s for Testing bitvector    inputs - valid
  0.01s for Testing bitvector    inputs - invalid
  0.01s for Testing containers   inputs - invalid - skipping BitsStruct
  0.01s for Testing bitlist      inputs - invalid
  0.00s for Testing uints        inputs - invalid - skipping uint128 and uint256
  0.00s for Testing boolean      inputs - valid
[NimScript] exec: nim c --out:./build/test_fixture_ssz_consensus_objects -r -d:chronicles_log_level=TRACE -d:const_preset=mainnet --verbosity:0 --hints:off -d:chronicles_log_level=TRACE -d:debug -d:disable_libbacktrace tests/official/test_fixture_ssz_consensus_objects.nim 

[Suite] Official - SSZ consensus objects  [Preset: mainnet]
[OK]   Testing    AggregateAndProof
[OK]   Testing    Attestation
[OK]   Testing    AttestationData

And it's only on 32-bit Azure, and presumably other 32-bit platforms if CI ran them.

It's not new from this PR, e..g, #1387 shows the same pattern. 32-bit Azure "fails", but doesn't, and other platforms don't have that issue.