Validate block before adding to SeenGossipBlockInput

### 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