add logic for handling sync committee off by one issue

[djrtwo]

addresses #2397

This is not yet comprehensive and I'm not really happy with how to explain the solution. Looking for feedback.

Essentially, being assigned to slot means you need to sign and broadcast for slot - 1.

[ralexstokes]

looks good to me -- sync committee members will have to start their task a slot early compared to when it may be understood just by reading the state but i don't see a way around this as these members are expected to sign over the previous slot so will hit this boundary condition when switching from one period to the other

[ajsutton]

This solves the original problem but it's a very weird quirk. I've had a bit of a go at implementing this in Teku and it's a bit messy particularly around the actual fork slot. It's likely to be equally messy around the next fork that changes sync committees as well.
We need to be very clear about which fork is used during those transitions. ie I'm creating a signature for slot 31 because I'm scheduled to be in a sync committee from slot 32 - do I use the rules of the fork for slot 31 (epoch 0) or 32 (epoch 1)? It's also a lot harder to reason about which state can be used to validate signatures and contributions because they aren't always using the committee for the epoch they're actually from. It's one of those weird quirks that's going to keep catching people by surprise I suspect.

That said, Teku is now working and performing all duties as expected. I suspect there are a few more edge cases around which will add some further complexity but I think it will be manageable.

And I can't really think of another way to solve this other than to just give up and make the SyncAggregate for the first slot of each sync committee always be empty which is simple but also a bit rubbish.

[hwwhww]

I updated the test cases and minor rephases on the parameters. The solution does seem not elegant but I couldn't figure out another way to solve it at lookahead and at processing the proof. :'(

Thanks, @ajsutton @djrtwo!

[ajsutton]

I guess the one other obvious option is to add previous_sync_committee to the state. It's not huge but is a bit of a shame to add it just for this.

[djrtwo]

I guess the one other obvious option is to add previous_sync_committee to the state. It's not huge but is a bit of a shame to add it just for this.

Right. The main issue there is that you then have exceptional for a single slot per period in the state transition