Enable gossip during optimistic sync for data columns

[gfukushima]

PR Description

This PR uses the flag subscribedToAllCustodySubnetsEnabled to reflect whether gossip should be enabled during optimistic sync.

Fixed Issue(s)

Fixes #10275

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Medium Risk
Changes gossip subscription behavior during optimistic sync and adds new config-driven gating, which could affect network load and data propagation if misclassified or miswired.

Overview
Enables data column sidecar gossip during optimistic sync when the node is considered a super node (either explicitly via new P2PConfig.isSubscribedToAllCustodySubnetsEnabled() or by having the maximum Fulu custody group count).

This introduces a reusable SuperNodeSupplier and threads it through BeaconChainController → Eth2P2PNetworkBuilder → GossipForkSubscriptions* → DataColumnSidecarGossipManager, which now gates optimistic-sync enablement via isEnabledDuringOptimisticSync(). It also centralizes “super node” detection via MiscHelpersFulu.isSuperNode, adds trace logging on sidecar gossip receipt, and updates tests/build deps accordingly.

^{Written by Cursor Bugbot for commit 19732b5. This will update automatically on new commits. Configure here.}

[zilm13]

It's not a good way to get this information.
Node could be subscribed to all custody subnets because:

• flag subscribe-custody..
• flag custody-override
• node is supernode because of the number of the validators served

Because number of the validators served could change dynamically on any epoch, this case should be handled too. For example check DataColumnSidecarRecoveringCustodyImpl how the flag isSuperNode is set. You need something similar but the check should be recurrent (because number of the validators could change), we do it usually onSlot, but there is no onSlot here, I'm not sure what will be the best option. We should do the check at least once per epoch.

[gfukushima]

I've changed the PR to contemplate the scenarios where you mentioned but the check isn't recurrent, I think this is better than the current state we can work on make the check every epoch on another PR, this might be useful in case the node stays in optimistic sync for too long, correct?

[zilm13]

It's a bad idea trying to duplicate logic of CustodyGroupCountManager. Moreover, you don't cover one of the most common customer's case: validator node with 128+ validators without any command line flags. It should be subscribed to all custody subnets. And it's a reason we need updates of the custody count status: (not all) validators are loaded on initialization stage, when constructor is called, keys decryption takes time, and real numbers breaks in a bit later, that's why we always try to follow status in other components.

[gfukushima]

since this gossip subscription is checked (for possible new subscriptions start) every epoch I believe we don't need a mechanism to keep checking constantly, I'm relying on the DB variable to tell if the node has changed status and is supernode when the change happens, if so before the epoch transition we should start the subscription for the data column gossip. If this isn't good enough than maybe we can think about a event based logic.

[zilm13]

it's debug or trace

[zilm13]

we shouldn't do this
how about something like this?
zilm13@24c4595

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.