[ntcore] Fix publish-triggered announcements being blocked by subscription announcements

[cjlawson02]

Description

Fixes #7680

This PR fixes a bug where publish-triggered announcements (with pubuid) were being blocked if a subscription-triggered announcement (without pubuid) was already sent to the same client for the same topic.

Problem

According to the NetworkTables 4.1 specification, the server shall respond to a publish message with an announce message containing the pubuid provided in the publish request. However, the current implementation had a bug where publish-triggered announcements were blocked in several scenarios:

1. Prefix subscription scenario: If a client had a prefix subscription (e.g., "/" or "/MyTable") and published a topic matching that prefix:

   • The CreateTopic call would trigger m_sendAnnounce, which broadcasts to subscribed clients
   • The publishing client would receive a subscription-triggered announcement (without pubuid), setting m_announceSent[topic] = true
   • When ClientPublish then called SendAnnounce(topic, pubuid), it was blocked because m_announceSent[topic] was already true

2. Retained topics after reconnection: When a client reconnects and republishes a retained topic:

   • The topic already exists in server storage (because it's retained)
   • If the client had previously subscribed to the topic, it may receive a subscription-triggered announcement first
   • The subsequent publish-triggered announcement is then blocked

3. Publishing without subscription: When a client publishes a topic without subscribing, the announcement should still be sent with the pubuid.

This violated the spec requirement that the server must respond to publish messages with an announcement containing the pubuid.

Solution

Modified SendAnnounce in both ServerClient4 and ServerClientLocal to allow publish-triggered announcements (with pubuid) even if a subscription-triggered announcement was already sent. The logic now:

• Blocks duplicate subscription-triggered announcements (without pubuid)
• Always allows publish-triggered announcements (with pubuid), ensuring spec compliance

Testing

Tested locally using an example robot application (Java/WPILib) and client application (TypeScript) running on localhost:

1. Retained topic with prefix subscription scenario:

   • Started the robot application which publishes /MyTable/Pose (protobuf topic)
   • Started the client application which:
     • Subscribes to prefix topics (/MyTable/ and '' for all topics)
     • Publishes /MyTable/AutoMode as a retained topic
   • Verified the client receives the announce message with pubuid immediately after calling publish() on the retained topic, even though it already received subscription-triggered announcements for the topic due to the prefix subscriptions
   • Confirmed no timeout errors occur (previously would timeout after 3 seconds with "Topic /MyTable/AutoMode was not announced within 3 seconds")

2. Retained topic reconnection scenario:

   • With the client connected and having published /MyTable/AutoMode as retained
   • Stopped and restarted the client application
   • Verified the client successfully republishes the retained topic on reconnection and receives the announcement with pubuid without timing out

3. General behavior verification:

   • Confirmed subscription-triggered announcements are still properly deduplicated
   • Verified the server complies with the NetworkTables 4.1 specification requirement that publish messages must receive an announce response with pubuid

The fix ensures that publish-triggered announcements (with pubuid) are always sent, even when subscription-triggered announcements have already been sent for the same topic.

Related Issues

Closes #7680

[PeterJohnson]

Thanks for the fix and detailed description. I'm worried about ecosystem impacts (e.g. testing with coprocessors, dashboards, other implementations) so don't really want to merge this in 2026. Can this be retargeted to the 2027 branch?

[cjlawson02]

Sure, at the very least let's get this into 2027. Your call on 2026, I think it would be helpful and low impact because it only causes another announcement message. IMO since it's early into the season a revert could be fine if necessary?