Skip column gossip verification logic during block production

[eserilev]

Issue Addressed

#7950

Proposed Changes

Skip column gossip verification logic during block production as its redundant and potentially computationally expensive.

[mergify]

Some required checks have failed. Could you please take a look @eserilev? 🙏

[jimmygchen]

@eserilev the sync job is failing, doesn't feel like your change would trigger this, but interestingly both fullnode and supernode are failing to sync, and stuck at SyncTransition, would you mind checking the logs to see what happened?
https://github.com/sigp/lighthouse/actions/runs/17475882997/job/49636337462?pr=7973

[jimmygchen]

I think we still need to do the following to avoid trying to publish & process them again:

1. check the availability cache and observed cache to make sure we exclude columns that we have seen
2. mark the column as seen in the observe cache

lighthouse/beacon_node/beacon_chain/src/data_column_verification.rs

Lines 450 to 466 in 9d2f55a

	verify_is_first_sidecar(chain, &data_column)?;
	// Check if the data column is already in the DA checker cache. This happens when data columns
	// are made available through the `engine_getBlobs` method. If it exists in the cache, we know
	// it has already passed the gossip checks, even though this particular instance hasn't been
	// seen / published on the gossip network yet (passed the `verify_is_first_sidecar` check above).
	// In this case, we should accept it for gossip propagation.
	if chain
	.data_availability_checker
	.is_data_column_cached(&data_column.block_root(), &data_column)
	{
	// Observe this data column so we don't process it again.
	if O::observe() {
	observe_gossip_data_column(&data_column, chain)?;
	}
	return Err(GossipDataColumnError::PriorKnownUnpublished);
	}

We've seen a race condition where the proposer node gets the columns from peers before the proposer publishes - a scenario where other nodes was able to fetch blobs from the EL and compute them faster than the proposer node.

[jimmygchen]

Just added a minor comment but i think we're close to merging this.

[jimmygchen]

I think we should also check for is_first_sidecar here, and we can avoid acquiring the cache write lock below (in the observe fn) if not needed - the cache read & write happens in burst around this time and it's time sensitive so it'd be great to avoid this.