Allow light client to verify signatures at period boundary

[etan-status]

As the sync committee signs the previous block, the situation arises at
every sync committee period boundary, that the new sync committee signs
a block in the previous sync committee period. The light client cannot
reliably detect this condition (e.g., assume that this is the case when
it is currently on the last slot of a sync committee period), because
the last couple slots of a sync committee period may not have a block.

For example, when receiving a LightClientUpdate that is constructed
as in the following illustration, it is unknown whether sync_aggregate
was signed by the current or next sync committee at attested_header.

                       
        slot N           N + 1   |            N + 2   (slot not sent!)
                                 |
  +-----------------+     \ /    |     +----------------+
  | attested_header | <--- X ----|---- | sync_aggregate |
  +-----------------+     / \    |     +----------------+
                        missed   |
                                 |
                          sync committee
                          period boundary

This patch addresses this edge case by including the slot at which the
sync_aggregate was created into the LightClientUpdate object.

Note that the signature_slot cannot be trusted beyond the purpose of
signature verification, as it could be manipulated to any other slot
within the same sync committee period and fork version, without making
the sync_aggregate invalid.

[etan-status]

Rebased to dev, also fixing a recent regression in get_sync_aggregate when requesting a signature from state.next_sync_committee that was introduced in #2826.

[etan-status]

Rebased to dev.

[etan-status]

Change method in which information about signing sync committee is included into the LightClientUpdate (Devconnect AMS feedback - see #2802 (comment))

Before:

• If update.next_sync_committee is empty, then update.sync_aggregate was signed by store.next_sync_committee, otherwise it was signed by store.current_sync_committee.

After:

• update.signature_slot contains the slot at which the update.sync_aggregate was signed. If that slot is in the store.finalized_header.slot's sync committee period, the update was signed by store.current_sync_committee. If it's in the next one, it was signed by store.next_sync_committee.

[etan-status]

• Fix get_sync_aggregate test function to use correct fork digest at fork boundary
• Removed unused block_root argument from get_sync_aggregate
• Return fork_digest / signature_slot that is used by get_sync_aggregate, for clarity

[ralexstokes]

I have not done a review of the changes but just going off the PR description:

it seems like we could use the current_slot input to validate_light_client_update to determine which sync committee period we are in, and then avoid adding more data to the light client update

what do you think about this?

[etan-status]

The current_slot input is based off local wall clock, which may be several days in the future in case of syncing historic data.

[ralexstokes]

ah good point, then I think adding the target slot makes a lot of sense :)

[hwwhww]

Sorry for the super late review @etan-status. Well done. LGTM!