[tor-dev] Reproducing #33598 "chutney does not fail on some SOCKS errors"

[c]

I asked on ticket https://bugs.torproject.org/33598 how to reliably
reproduce SOCKS errors so that it would be easier to determine when the
underlying issue is properly fixed, rather than running into the
possibility of race conditions (as the current workaround depends on
"waiting long enough" for connections to succeed most of the time).

In #tor-dev I believe it was arma who pointed me toward the right
direction, but that still leaves me with unresolved questions. It was
suggested that I can attempt SOCKS connections to an invalid host/port
versus a valid one, in order to have a reliable failure case for
testing. But in the context of Chutney I believe we only want to
attempt local connections, correct? So either attempting connection to
127.0.0.0/8 on a known-closed port, or perhaps more simply 0.0.0.0 on
any port, would be a reliable case to use, correct?

Also from my comment on #33598:

> Assuming workaround is at ​Traffic.py:441? I see the timeout was
> adjusted in ​95ce144c which has more changes than just that line.

and

> will decreasing the timeout back to 0.2 be enough to encourage
> failure?

Last question: I looked for a bit, but where is Chutney actually
initiating SOCKS connections to Tor during tests? I still find it hard
to follow especially when I am going in blind for much of this.

Caitlin