Use headstate for recent checkpoints

[potuz]

In the event a peer hasn't imported slot 0 and attests for slot 31 as target during slot 0. All prysm nodes that have seen the block in slot 0 and are receiving these attestations, go through the following in gettAttPrestate

	// If the attestation is recent and canonical we can use the head state to compute the shuffling.
	headEpoch := slots.ToEpoch(s.HeadSlot())
	if c.Epoch == headEpoch {

This code path is missed since c.Epoch > headEpoch.

Later in the code we hit:

	// Do not process attestations for old non viable checkpoints otherwise
	ok, err := s.cfg.ForkChoiceStore.IsViableForCheckpoint(&forkchoicetypes.Checkpoint{Root: [32]byte(c.Root), Epoch: c.Epoch})
	if err != nil {
		return nil, errors.Wrap(err, "could not check checkpoint condition in forkchoice")
	}
	if !ok {
		return nil, errors.Wrap(ErrNotCheckpoint, fmt.Sprintf("epoch %d root %#x", c.Epoch, c.Root))
	}

Forkchoice does not take c as viable for checkpoint because the only child (slot 0) does not satisfy the condition in it:

	for _, child := range node.children {
		if child.slot > epochStart {
			return true, nil
		}
	}

Thus we are flooded with the message

	ErrNotCheckpoint = errors.New("not a checkpoint in forkchoice")

This should result in poor attestation performance in slot 0 and inclusion in slot 1.

This PR implements that if the incoming checkpoint has epoch higher than the current head root and the block is canonical (this can only happen if the checkpoint is the actual headroot) then we return as state the head state advanced to the current slot.

Reviewer be advised: check about possible performance problems because of the slot processing.

[terencechain]

Why wouldn't we want to cache the result of this in the check point attestation cache? Seems to me if there are N attestations trigger this condition then we will need to do this N times which could become a dos vector. Are state copy and process slots here that cheap?

[potuz]

if the NSC cache is a hit wouldn't this be already in the checkpoint cache? hmm probably better to follow on Slack

[potuz]

You're right, we're getting these messages on attestations up to slot 5, so they are not in the NSC, I updated the checkpoint cache here.

[nisdas]

I am worried about advancing slots this way, this becomes expensive. why can't we just return the read only head state here ? If slot 0 is missed, the head state should still be able to verify an attestation from slot 31

[potuz]

the attestation is not from slot 31, it's from slot 0, you need to check that the attester is in the right committee

[nisdas]

you have to move it up before you fetch the head state.

[terencechain]

LGTM. The conditions make sense. We should clean up getAttPreState with getRecentPreState to remove the overlapping code later on