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

Ever since we started scrubbing log messages, with the help of regexes
for https://bugs.torproject.org/21304 logging has become more CPU
intensive due to our use of regular expressions.

Logging the byte count of every incoming and outgoing message at the
proxy-go instances was taking up a lot of CPU and contrubuting to the
high CPU usage seen in https://bugs.torproject.org/33211.

https://cloud.google.com/appengine/docs/standard/go111/go-differences
This is untested, because I wasn't actually able to deploy without
enabling Cloud Build and setting up a billing account.

Some proxies currently send ?client_ip=0.0.0.0 because of an error in
how they attempt to grep the address from the client's SDP. That's
inflating our "%d/%d connections had client_ip" logs. Instead, treat
these cases as if the IP address were absent.
https://bugs.torproject.org/33157
https://bugs.torproject.org/33385

Unless something externally called Write after Close, the
writeLoop(ws, pr2) goroutine would run forever, because nothing would
ever close pw2/pr2.
https://bugs.torproject.org/33367#comment:4

Instead of string manipulation.

Unfortunately, the "public" RTCIceTransportPolicy was removed.

https://developer.mozilla.org/en-US/docs/Web/API/RTCConfiguration#RTCIceTransportPolicy_enum

Trac: 19026

go vet was complaining,

common/websocketconn/websocketconn.go:56:2: unreachable code

We had already implemented Read, Write, and Close. Pass RemoteAddr,
LocalAddr, SetReadDeadline, and SetWriteDeadline through to the
underlying *websocket.Conn. Implement SetDeadline by calling both
SetReadDeadline and SetWriteDeadline.

https://bugs.torproject.org/33144

Makes the following changes:
 * permits concurrent Read/Write/Close
 * converts certain CloseErrors into io.EOF

https://bugs.torproject.org/33144

https://bugs.torproject.org/33144

This slightly changes some log messages.