test(network): give the reconnect test a budget above the backoff

[stevenvegt]

Problem

TestNetworkIntegration_OutboundConnection11Reconnects fails intermittently under load:

--- FAIL: TestNetworkIntegration_OutboundConnection11Reconnects
    time-out while waiting for node 1 to reconnect to node 2

The test restarts node2 and gives node1 defaultTimeout, 5 seconds, to reconnect by itself. That reconnect races the backoff. When a connection that was up is closed cleanly, connect() ends with:

// Connection was OK, but now disconnected. Add a random wait to prevent simultaneous reconnecting.
contact.backoff.Reset(RandomBackoff(time.Second, 5*time.Second))

and connectLoop only picks up expired backoffs on a time.NewTicker(time.Second). So the worst case is 5 seconds of backoff plus up to a second before the loop notices, before dialling and the TLS handshake even start. The budget is exceeded before the node does anything wrong.

This is not new and is not caused by any recent change: the random reset came in with #1874 (2023-02-24) and defaultTimeout predates it. I hit it twice while preparing the backports of #4467 and #4562 and checked the counterfactual: 6 clean full-package runs with #4562's changes, 4 clean runs without them, and 10 clean runs of the test in isolation. It only shows up when the whole package runs and the machine is busy, which is also why it is rare in CI rather than absent.

Change

The reconnect wait gets its own budget of 15 seconds, comfortably above the 5 second maximum backoff plus the 1 second tick, with the arithmetic written down next to the constant. The two other waits in the test are an initial connect (no prior backoff) and a disconnect, neither of which races a backoff, so they keep defaultTimeout.

Test-only, no production code touched.

Verification

This is a timing budget, so there is no deterministic RED to show: the test passes both before and after when the machine is quiet. -count=10 passes on this branch. What the change does is remove a worst case that was already outside the budget by construction, which is visible in the two constants rather than in a test run.

An alternative would be to have the test force an immediate reconnect, but that would defeat the point of the test, which is that the node reconnects on its own.

Related: #4321 reports the same shape (a fixed wait that propagation can exceed under load) on the gossip e2e test.