In practice, we only ever use ClientMap with ClientID. This
specializiation enables better optimization of this frequently called
function.

Before:
```
snowflake/common/turbotunnel$ go test -bench BenchmarkSendQueue -benchtime 10s -run '$^' -v
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    100000000              155.4 ns/op
PASS
ok      gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel  15.661s
```

After:
```
snowflake/common/turbotunnel$ go test -bench BenchmarkSendQueue -benchtime 10s -run '$^' -v
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    176652633               65.69 ns/op
PASS
ok      gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel  18.473s
```

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

The version of x/sys we're using requires go1.17 or later

This is a workaround for older versions of android that do not trust
the Let's Encrypt root certificate.
tpo/anti-censorship/pluggable-transports/snowflake#40087

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
(#40270).

Related: #40198

Related: tpo/anti-censorship/team#86

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

This is meant to reduce overall allocations. See past discussion at
tpo/anti-censorship/pluggable-transports/snowflake#40260 (comment 2885524) ff.

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
tpo/anti-censorship/pluggable-transports/snowflake#40260 (comment 2885832).
The noise-generating loop from the test was continuing to run while the
benchmarks were running.

Since d2858aeb the caller is permitted
to reuse its slice again.

This error return was lost in 11f08462;
i.e. !31.

Fixes #40043.

Jill authored 2 years ago and shelikhoo committed 2 years ago

- webrtc and dtls libs got the "Skip Hello Verify" patches applied

Link: https://github.com/pion/dtls/pull/513
Link: https://github.com/pion/webrtc/pull/2433

Revert "Take ownership of buffer in QueuePacketConn QueueIncoming/WriteTo"

See merge request tpo/anti-censorship/pluggable-transports/snowflake!140

This reverts commit 839d2218. (Except for
the added benchmarks in queuepacketconn_test.go.) This change
corresponds to the issues #40187 and #40199.

The analysis in tpo/anti-censorship/pluggable-transports/snowflake#40199
was wrong; kcp-go does reuse the buffers it passes to
QueuePacketConn.WriteTo. This led to unsynchronized reuse of packet
buffers and mangled packets observable at the client:
tpo/anti-censorship/pluggable-transports/snowflake#40260.

Undoing the change in QueuePacketConn.QueueIncoming as well, for
symmetry, even though it is not implicated in any correctness problems.

For #40260.

https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/commits/fc89e8b10c3ff30db2079b2fb327d05b2b5f3c80/projects/common/bridges_list.snowflake.txt

* Use port 80 in placeholder IP addresses
  tpo/applications/tor-browser-build!516
* Enable uTLS
  tpo/applications/tor-browser-build!540
* Shorten bridge line (remove stun.voip.blackberry.com)
  tpo/applications/tor-browser-build!558
* Add snowflake-02 bridge
  tpo/applications/tor-browser-build!571