With these not being closed, they were continuing to consume resources
after the return of the test function, which was affecting the later
BenchmarkSendQueue.
Before:
```
snowflake/common/turbotunnel$ go test -bench BenchmarkSendQueue -v
=== RUN TestQueueIncomingOversize
--- PASS: TestQueueIncomingOversize (0.00s)
=== RUN TestWriteToOversize
--- PASS: TestWriteToOversize (0.00s)
=== RUN TestRestoreMTU
--- PASS: TestRestoreMTU (0.00s)
=== RUN TestRestoreCap
--- PASS: TestRestoreCap (0.00s)
=== RUN TestQueuePacketConnWriteToKCP
--- PASS: TestQueuePacketConnWriteToKCP (1.01s)
goos: linux
goarch: amd64
pkg: gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel
cpu: Intel(R) Core(TM) i5 CPU 680 @ 3.60GHz
BenchmarkSendQueue
BenchmarkSendQueue-4 8519708 136.0 ns/op
PASS
ok gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel 3.481s
```
After:
```
snowflake/common/turbotunnel$ go test -bench BenchmarkSendQueue -v
=== RUN TestQueueIncomingOversize
--- PASS: TestQueueIncomingOversize (0.00s)
=== RUN TestWriteToOversize
--- PASS: TestWriteToOversize (0.00s)
=== RUN TestRestoreMTU
--- PASS: TestRestoreMTU (0.00s)
=== RUN TestRestoreCap
--- PASS: TestRestoreCap (0.00s)
=== RUN TestQueuePacketConnWriteToKCP
--- PASS: TestQueuePacketConnWriteToKCP (1.02s)
goos: linux
goarch: amd64
pkg: gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel
cpu: Intel(R) Core(TM) i5 CPU 680 @ 3.60GHz
BenchmarkSendQueue
BenchmarkSendQueue-4 11620237 105.7 ns/op
PASS
ok gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel 3.244s
```
When the orport-srcaddr option is set, we bind to a source IP address
before dialing the ORPort/ExtORPort. tor similarly binds to a source IP
address when OutboundBindAddress is set in torrc. Since tor 0.4.7.13,
tor sets IP_BIND_ADDRESS_NO_PORT, and because problems arise when some
programs use IP_BIND_ADDRESS_NO_PORT and some do not, we also have to
start using IP_BIND_ADDRESS_NO_PORT when we upgrade tor
(tpo/anti-censorship/pluggable-transports/snowflake#40270).
Related: tpo/anti-censorship/pluggable-transports/snowflake#40198
It was silently exiting at the "recordingStart":"2022-09-23T17:06:59.680537075Z"
line, the first line whose length (66873) exceeds
bufio.MaxScanTokenSize. Now distinctcounter exits with an error status
instead of reporting partial results.
$ ./distinctcounter -from 2023-01-01T00:00:00Z -to 2023-01-10T00:00:00Z -in metrics-ip-salted.jsonl
2023/04/20 13:54:11 unable to count:bufio.Scanner: token too long
The noise-generating goroutine was meant to stop when the parent
function returned and closed the `done` channel. The `break` in the loop
was wrongly exiting only from the `select`, not from the `for`.
This was the cause of banchmark anomalies in
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40260#note_2885832.
The noise-generating loop from the test was continuing to run while the
benchmarks were running.
