This adds a new type of SnowflakeEvent. EventOnProxyStats is triggered
by the periodic task run at SummaryInterval and produces an event with a
proxy stats output string.
This fixes a regression introduced in 9fdfb3d1, where the list of front
domains always contained an empty string if none were supplied via the
commandline options, causing rendezvous failures for both amp cache and
domain fronting. This fix checks to see whether the commandline option
was supplied.
Introduce a new commandline and SOCKS argument for comma-separated
domain fronts rather than repurposing the old one so that we can
maintain backwards compatability with users running old versions of the
client. A new bridge line shared on circumvention settings could have
both the front= and fronts= options set.
This commmit changes the command-line and Bridge line arguments to take
a comma-separated list of front domains. The change is backwards
compatible with old Bridge and ClientTransportPlugin lines. At
rendezvous time, a front domain will be randomly chosen from the list.
I.e. match it with an unrestricted proxy (if there is one).
The old behavior exists since the inception of the restricted vs
unrestricted feature, i.e. 0052c0e10c
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
