https://bugs.torproject.org/33897#comment:4

The other interfaces in client/lib/interfaces.go exist for the purpose
of running tests, but not Snowflake. Existing code would not have worked
with other types anyway, because it does unchecked .(*WebRTCPeer)
conversions.

A short write will result in a non-nil error. It's an io.PipeWriter
anyway, which blocks until all the data has been read or the read end is
closed, in which case it returns io.ErrClosedPipe if not some other
error.

This allows us to remove the internal errorChannel.

WaitForReset is not used since 70126177.

https://bugs.torproject.org/33984

OnICEGatheringStateChange is no longer called when candidate gathering
is complete. SetLocalDescription kicks off the gathering process.

https://bugs.torproject.org/28942#comment:28
https://bugs.torproject.org/33157#comment:2

Provide NewBytesSyncLogger that returns an opaque data structure.
Automatically start up the logging loop goroutine in NewBytesSyncLogger.

You would have been able to do, for example,
snowflake.(*WebRTCPeer).AddInbound(...).

This allows multiple SOCKS connections to share the available proxies,
and in particular prevents a SOCKS connection from being starved of a
proxy when the maximum proxy capacity is less then the number of the
number of SOCKS connections.

This is option 4 from https://bugs.torproject.org/33519.

The difficulty here is that the whole point of turbotunnel sessions is
that they are not necessarily tied to a single WebSocket connection, nor
even a single client IP address. We use a heuristic: whenever a
WebSocket connection starts that has a new ClientID, we store a mapping
from that ClientID to the IP address attached to the WebSocket
connection in a lookup table. Later, when enough packets have arrived to
establish a turbotunnel session, we recover the ClientID associated with
the session (which kcp-go has stored in the RemoteAddr field), and look
it up in the table to get an IP address. We introduce a new data type,
clientIDMap, to store the clientID-to-IP mapping during the short time
between when a WebSocket connection starts and handleSession receives a
fully fledged KCP session.

The client opts into turbotunnel mode by sending a magic token at the
beginning of each WebSocket connection (before sending even the
ClientID). The token is just a random byte string I generated. The
server peeks at the token and, if it matches, uses turbotunnel mode.
Otherwise, it unreads the token and continues in the old
one-session-per-WebSocket mode.

Copied and slightly modified from
https://gitweb.torproject.org/pluggable-transports/meek.git/log/?h=turbotunnel&id=7eb94209f857fc71c2155907b0462cc587fc76cc
https://github.com/net4people/bbs/issues/21

RedialPacketConn is adapted from clientPacketConn in
https://dip.torproject.org/dcf/obfs4/blob/c64a61c6da3bf1c2f98221bb1e1af8a358f22b87/obfs4proxy/turbotunnel_client.go
https://github.com/net4people/bbs/issues/14#issuecomment-544747519

Formerly we waiting until *both* directions finished. What this meant in
practice is that when the remote connection ended, copyLoop would become
useless but would continue blocking its caller until something else
finally closed the socks connection.

Now that the web proxies are in a different repository, no need to
distinguish the two.

We're moving all web proxy code to a different repsitory.

We're moving all web proxy code to another repository.

https://bugs.torproject.org/33800

This will prevent a bug where tor skips bandwidth events for local
addresses (see https://bugs.torproject.org/33693)

Trac: 19026

Trac: 19026

https://en.wikipedia.org/wiki/Letter_case#Special_case_styles

This existed solely for testing purposes and is no longer being
maintained.

We no longer need standalone get commands now that we are using go
modules.

https://bugs.torproject.org/33429