VC: attestations and sync commitee messages should occur on first of block/slot +4s

[tersec]

https://github.com/ethereum/consensus-specs/blob/v1.2.0-rc.3/specs/phase0/validator.md#attesting states

A validator should create and broadcast the attestation to the associated attestation subnet when either (a) the validator has received a valid block from the expected block proposer for the assigned slot or (b) 1 / INTERVALS_PER_SLOT of the slot has transpired (SECONDS_PER_SLOT / INTERVALS_PER_SLOT seconds after the start of slot) -- whichever comes first.

and https://github.com/ethereum/consensus-specs/blob/v1.2.0-rc.3/specs/altair/validator.md#prepare-sync-committee-message states

This logic is triggered upon the same conditions as when producing an attestation. Meaning, a sync committee member should produce and broadcast a SyncCommitteeMessage either when (a) the validator has received a valid block from the expected block proposer for the current slot or (b) one-third of the slot has transpired (SECONDS_PER_SLOT / INTERVALS_PER_SLOT seconds after the start of the slot) -- whichever comes first.

The VC does not appear to respond to condition (a) for sync committee messages: https://github.com/status-im/nimbus-eth2/blob/8be964a152a25d6954aa38d48e81d7575ea1fc6c/beacon_chain/validator_client/sync_committee_service.nim#L381-L402

[jclapis]

Confirmed in my testing, both attestations and sync committee messages always have a delay > 0 when running in split BN / VC mode. When just using the BN only, the delays are almost always negative.

[jclapis]

Just leaving a note that this is still present in the VC with 22.11.0 - all of my attestations in the split-process config have a positive delay (>4s) which causes some of them to have >0 inclusion distances.

[tersec]

https://github.com/status-im/nimbus-eth2/pull/6331