MaxBytesReader is only documented for server side reads, so we're using
a local limitedRead function instead that uses an io.LimitedReader.

Declared limits in a commented constant

This is a fix for #26348

This fixes a bug introduced by the deadlock patch for ticket #25688.

This is related to the proxy-go deadlock bug #25688. If a client doesn't
do anything with the SDP answer, a token will get lost. Added a timeout
after a minute that checks the PeerConnection state and destroys the
peer connection and returns a token if did not yet succeed

This is a fix for the proxy-go deadlock bug (ticket #25688). The
assumption that OnIceComplete is always followed by a successful
connection where OnDataChannel has been called turns out not to occur in
practice. OnICEComplete looks like it is being deprecated in other
libraries anyway, so it's safer to just remove it.

https://snowflake-reg-test.appspot.com/ for the client (needs domain fronting)
https://snowflake-broker.bamsoftware.com/ for the proxies (no fronting)

Note that fronting to App Engine doesn't currently actually work because
of https://bugs.torproject.org/25804; this commit doesn't change that.

https://bugs.torproject.org/25344

5s matches DEFAULT_BROKER_POLL_INTERVAL in the JavaScript proxy.

This is set up so as long as the actual HTTPS requests take less time
than pollInterval, there will a steady one poll per pollInterval. If the
HTTPS requests take longer than that, there will be no delay between
polls.

From https://trac.torproject.org/projects/tor/ticket/21312#comment:33

Follow up to ff8f3851

Similar to c834c76f

"net.IPAddr composite literal uses unkeyed fields"

Call conn.RemoteAddr() before entering the datachannelHandler goroutine.
This is a workaround for the hang described at
https://bugs.torproject.org/18628#comment:8

Remove global opt struct.

This variable was being written to by multiple goroutines, overwriting
the Path to either "/proxy" or "/answer" as necessary, which was racy.

This prohibits some nonsense like "./proxy-go -capacity -550", which
otherwise results in a panic like:

INFO: configuration.go:174: Created Configuration at  &{[{[stun:stun.l.google.com:19302]  }] All Balanced }
panic: makechan: size out of range

math/rand always uses a deterministic seed. The sequence of session IDs
was therefore always the same:
	Uv38ByGCZU8WP18PmmIdcg
	lWbHTRDYaB0NhtHpHgAWeQ
	...

Multiple copies of this program would have had session ID collisions. I
don't know what the consequences of that would be.