Test Details Overview

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 Results

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 - -