Validate block before adding to SeenGossipBlockInput

[twoeths]

Describe the bug

This is similar motivation to https://github.com/ChainSafe/lodestar/pull/7955 found during peerDAS devnet For blobs and block, we need to validate them before adding to SeenGossipBlockInput cache But it's not as easy as #7955 because handling unknown_parent is critical to keep a node synced. We need to coordinate this fix while refactoring UnknownBlock sync cc @matthewkeil

When we receive a block with unknown_parent at gossip handler, we should not add to SeenGossipBlockInput and need a place to retry this block The retry of a block received from gossip should be at NetworkProcessor because UnknownBlock sync has no idea about validateBeaconBlock() function In NetworkProcessor we already have awaitingGossipsubMessagesByRootBySlot when attestations has an unknown block head. We can use similar strategy to store up to 100 (same to MAX_PENDING_BLOCKS of UnknownSync) slots of blocks and blobs. Once we process an ancestor block input, we can reprocess all of them Need to make sure we don't have to deserialize gossip messages again Also the unknown_parent event in UnknownBlock is likely deprecated and removed. In case of unknown_parent just emit an unknown_block event

Expected behavior

• For blobs and block, we need to validate them before adding to SeenGossipBlockInput cache
• Need to make sure unknown_parent events work. if block A3, A2, A1 are pending because of A0, once A0 is processed we need to process all descendant blocks
• Need to sync a node up to head multiple times to make sure it works until it's synced
• Need to prove once a node is synced, and got unknown_parent event, the sync status could be recovered

Steps to reproduce

No response

Additional context

No response

Operating system

Linux

Lodestar version or commit hash

unstable