The logic to subscribe / unsubscribe topics at a fork is the following:

network/src/service.rs holds three timer futures:

• next_fork_subscriptions: Calls subscribe_new_fork_topics and subscribes to any existing topics but with the new fork-digest. Also, subscribes to new topics returned from fork_core_topics(new_fork)
• next_unsubscribe: Calls unsubscribe_from_fork_topics_except to unsubscribe all topics expect those with the current fork-digest
• next_fork_update: Sets new futures for next_fork_subscriptions, next_unsubscribe and next_fork_update

Outside of a fork-boundary the network service may receive a SubscribeCoreTopics message and subscribe to all topics returned by core_topics_to_subscribe

With peerdas

Now we have a new topic transition point where:

• we need to unsubscribe to a topic in all fork-digests
• do not rotate topics on a new fork-digest

Note that data_columns topics are not core topics, so we may not have to subscribe ahead of time. If we can accept a few slots of instability while we find peers we can avoid the complexity.