Give peer reachout a component of its own and let its trigger wake only its loop (#5229) * Rewrite the reachout tests and test the address reachout `network.disable_reachout` waited a second and checked that no reachout had happened, which a node whose loops had not run yet passes too. It now starts a node without the flags after the flagged one and checks that the second went round all three reachout loops while the first went round none. `network.reconnect_cached` drops the six bootstrap flags it set, none of which touches the realtime channels it reconnects, and gets a block description and step comments. `network.reachout` is new: it reaches out to an address, checks the callback reports the endpoint it connected to, and that a second reachout to the connected peer sends a keepalive down the existing channel instead of opening another. The rep crawler is off for now, since its reachout trigger also wakes the keepalive loop. * Let a reachout trigger wake only the preconfigured reachout loop The five network loops wait on one condition variable with no predicate, so `trigger_reachout`, which the rep crawler calls every round while it lacks quorum, also ran a keepalive round and a cleanup round each time. Keepalives then went out at the crawler's cadence instead of the keepalive period, and each cleanup round added a whole interval to the duplicate filter's epoch, aging entries out in a fraction of the configured cutoff. Every loop now waits with a predicate on `stopped`, which re-waits to the same deadline on any other wake-up, and the preconfigured loop waits on a trigger flag set under the mutex, as the telemetry trigger does. Three tests pin it down: a hundred triggers leave the keepalive and cleanup counters alone, do not age the filter, and bring the preconfigured reachout forward. `network.reachout` no longer needs the rep crawler off to see a quiet keepalive loop. * Move peer reachout out of the network into `network_reachout` The network ran five loops on one condition variable: cleanup, keepalive and three kinds of reachout, the last with a trigger from the rep crawler that is what woke the other loops before the previous fix. Reaching out to peers is a concern of its own, like the peer history and the rep crawler, so it gets its own component with its own threads, condition variable and resolver: the loops over keepalive peers, cached peers and preconfigured peers, the address reachout the keepalive RPC uses, and the trigger, which the rep crawler now asks the node for. `merge_peer`, `track_reachout` and `not_a_peer` stay on the network, since they answer whether this node may connect to an endpoint and the channel container asks them too. The reachout config keys stay under the network's table and the stats keep their type. The reachout tests move to network_reachout.cpp under the `network_reachout` suite: `disabled`, `resolve_and_connect`, the three trigger tests and `reconnect_cached`.
__________
Type: commit
Hash: 4f8993c84eb39f02ebe82f858dc4eeaba4ac26ba
Created: yesterday
__________
gr0v1ty/nano-node:4f8993c84eb39f02ebe82f858dc4eeaba4ac26ba
| Test Case | Status | Duration | Median Deviation | Log | Graph |
|---|---|---|---|---|---|
| 5n4pr_conf_10k_bintree | PASS | 107 s | -5.0 s | - | Show |
| 5n4pr_conf_10k_change | PASS | 168 s | 32.0 s | - | Show |
| 5n4pr_conf_change_dependant | PASS | 108 s | -4.0 s | - | - |
| 5n4pr_conf_change_independant | PASS | 108 s | -9.0 s | - | - |
| 5n4pr_conf_send_dependant | PASS | 112 s | -4.0 s | - | - |
| 5n4pr_conf_send_independant | PASS | 108 s | -5.0 s | - | - |
| 5n4pr_rocks_10k_bintree | PASS | 107 s | -6.0 s | - | - |
| 5n4pr_rocks_10k_change | PASS | 144 s | -23.0 s | - | - |