Interop tests

[djrtwo]

Increase test coverage to address some of the holes found at interop
https://github.com/djrtwo/interop-test-cases

• crosslink tests for a tied crosslink between two epochs, favoring the previous epoch
• rewards tests for a few basic scenarios
• rewards test for duplicate attestation inclusion

Also:

• fix test signatures for aggregate attestations in tests

Note:
Could either continue deeper into the rewards tests right here or just get it merged for release. Open to discussion

[djrtwo]

@protolambda Can you take a look at these soon?

[protolambda]

Updated some use of the test util code for attestations. And parked a new test for crosslink data-root tie-breaking on a branch: dataroot-tie-test. This requires the phase-0 lines # [to be removed in phase 1] to actually be removed, for a later PR.

[protolambda]

Documenting another two edge-cases in tiebreaking of crosslinks from interop, but unsure about reproduction in a test for now:

I:

• Attestations with different attesters and crosslink end-epoch, but otherwise identical data
• The attestations have different attesters, but same total weight
• Winning crosslink attesters are chosen based on insertion order of attestations

Would it be a good idea to change the spec to tie-break more explicitly on insertion order?

II:

• Same crosslink data, but multiple attestations with different attesters attesting to it.
• Tiebreak is won by one of them, doesn't matter which as they are the same crosslink.
• Aggregate winning attesters from multiple attestations that repeated this crosslink.

For II, an optimized version (zrnt...) may OR the attestations into a minimal bitfield per crosslink to rank, and then not have to aggregate at the end or repeatedly when computing the weights (sum of effective balance of unique attesters) for ranking. Having a test with multiple attestations, same crosslink, and overlapping participation may be valuable.

[protolambda]

Looks good, cleaned up some minor things for attestation signing. And went through a few more edge cases, but need to decide on what to include in release (do we write out more edge-cases?), and continue on the testing tool (I prefer to focus on catching more things, and then write more tests later again).

[djrtwo]

This requires the phase-0 lines # [to be removed in phase 1] to actually be removed, for a later PR.

Checked it out. Looks good.

---

Ready to merge this. Going to prepare a release. May or may not get to some of the other tests before release