Fix network bridge silent death when transport exception occurs during broker info handshake

[TylerMurali]

Summary

Fixes #1864

• Bug: In DemandForwardingBridgeSupport.start(), the onException() handlers for both local and remote transports return early when futureBrokerInfo is not done, skipping serviceLocalException()/serviceRemoteException(). This prevents the reconnection chain (fireBridgeFailed() → discoveryAgent.serviceFailed()) from firing, causing the bridge to silently die without reconnection.
• Fix: Remove the two return statements so the exception service methods always fire. The future cancellation is preserved. This is a 2-line change.
• Evidence: The duplexInboundLocalBroker handler in the same file unconditionally calls serviceLocalException(), confirming the intended behavior.

Production Validation

Tested in production with 15 network connectors over 3.5 months. The bug path was hit 12 times (transport exceptions during broker info handshake), and all 12 resulted in successful reconnection after the fix. Prior to the fix, these were permanent connector losses requiring broker restarts.

Test Plan

• testBridgeReconnectsAfterHandshakeFailure — Reproduces the exact bug path: uses a fake server socket that accepts TCP connections but never sends BrokerInfo, so onException fires while futureBrokerInfo is NOT done. Fails without the fix, passes with it.
• testBridgeReconnectsAfterRemoteBrokerRestart — General reconnection test: single remote broker stop/restart cycle
• Existing tests pass: DemandForwardingBridgeTest, DemandForwardingBridgeSupportTest, NetworkReconnectTest

[cshannon]

I am still investigating this, but the first observation is the test case here might need some improvement. I ran this test without the included fix and I tried commenting out the assertion here and the tests continued and both passed and the bridges seemed to reconnect so it's not really demonstrating the issue of silently not reconnecting as described from what I can tell.

[cshannon]

So I am not saying there is not an issue here, but I'm trying to figure out what I am missing because the reconnect logic still seems to be fired even without this fix because the TimeoutException is still being passed along to bridge failed. Maybe there is a race condition.

Here is what I am seeing when I run the test case and step through things without the fix:

1. EOFException does happen first and is caught here and aborts as noted
2. However, after that happens the call to collectBrokerInfos() is called here.
3. collectBrokerInfos() triggers a timeout exception and is caught here
4. bridgeFailedError(timeoutException) is called here which passes in that timeout exception and called bridgeFailed() on the listener
5. discoveryServiceAgent.sericeFailed(event) is invoked here which in turn kicks off the reconnect logic

[cshannon]

So digging in a bit more I see that when the exception happens it doesn't pass the IOException obviously, but futureRemoteBrokerInfo.cancel(true); is called which triggers the TimeoutException. That does get passed to serviceRemoteException() in collectBrokerInfos() which should trigger the reconnect.

So the part that I am confused about is your saying that returning early prevents fireBridgeFailed() from firing, but from what I can see returning early first calls cancel on the futureRemoteBrokerInfo which in turn cause the TimeoutException which is caught later and triggers fireBridgeFailed()