Maybe get auto_outbound_factory() and _create_auto_outbound_listener() to have the same interface? That is, change _create_auto_outbound_listener() to also return the listener? Then this will be more consistent:

                if self.auto_outbound_factory:
                    actual_to_addr, actual_to_port, listener = self.auto_outbound_factory(i)
                else:
                    actual_to_addr, actual_to_port, listener = self._create_auto_outbound_listener(listener)

and then we can have one function (pointer) that either points to the default one or to the user-provided one and here just:

actual_to_addr, actual_to_port, listener = self.auto_outbound_factory(i)

without an if condition. That would mean to also rename _create_auto_outbound_listener() to auto_outbound_factory() and remove the line self.auto_outbound_factory = None from BitcoinTestFramework::__init__().

Feel free to ignore if you do not see this as an improvement.

I like that suggestion - took it!

Maybe this needs format_addr_port() as well, in case the address happens to be IPv6 and needs to be enclosed in []?

The config address is hardcoded in _setup_auto_outbound_mode to 127.0.0.1, so IPv6 shouldn't be a concern I think?

Right, only if changed in the future. Or if somebody is playing with this locally and changes it to fir their environment. An address like ::1 would also upset this because it would result in -proxy=::1:12345 which I guess will result in "syntax" error.

The other helper functions
has_regular_outbounds(),
has_extra_block_relay_peer() and
has_extra_full_outbound_peer()
take a node argument. Maybe add such argument also to disconnect_last_block_relay_peer() for consistency?

PS1 same for wait_for_network_specific_peer()
PS2 all of those end up using self.nodes[0], so another option is to drop the node argument from all.

I decided to drop the node arg everywhere.

Is there an unlikely scenario that a stale-tip extra-outbound connection is initiated after advancing the mocktime and before self.generate(node, 1)? And eventually causing the interference that this is trying to disable?

I think probably not in practice - CheckForStaleTipAndEvictPeers fires every 45 seconds (on a steady clock, not influenced by the mocktime bump). So I think this means it would only fire if 45 real seconds passed since the last mockscheduler call, which seems very unlikely.

Is it possible that the node already has at least one connection to all reachable networks when this function starts? Would that result in timeouts due to has_extra_full_outbound_peer(node) never returning True?

To avoid this, the test first adds 100 IPv4 addresses to addrman, then waits for the regular otubound connections (setup_peers), and only then the onion and cjdns addresses are added to addrman. So I think it shouldn't be possible.

What about the tor and cjdns connections being established after adding to addrman and before wait_for_network_specific_peer() is called?

The order in which bitcoind makes connections is a bit undeterministic and also which connection is it going to make is not 100% deterministic either (e.g. is the next connection going to be full-outbound or feeler or net-specific?). #34410 addresses that by not relying only on the connection index but looking up the requested-to address and port in the debug log in order to figure out what the connection is.

That said, auto_outbound_factory() might benefit from getting more information about the connection, in addition to its index, like the requested address and port:

- actual_to_addr, actual_to_port, listener = self.auto_outbound_factory(i)
+ actual_to_addr, actual_to_port, listener = self.auto_outbound_factory(i, requested_to_addr, requested_to_port)