GitLab

This compliments the poll the rate adjustment on proxy failures to
address proxy matching issues. Since we cannot determine our NAT type
directly for browser-based proxies, we assume a restricted NAT type if
the datachannel fails to open.

If we stop getting keep-alive pings for some timeout period, close the
stale connection. This solves bug #31278 where chrome proxies hang open
on an idle connection.

Trac: 34127

Trac: 34140

This might just be an issue with node-webrtc but seems a harmless
workaround.

Trac: 34126

Trac: 34128

Trac: 34132

Trac: 34127

Trac: 33365
Trac: 33112

If the proxy succeeds in opening a datachannel to the client, decrease
the poll interval. If they fail, increase the poll interval. This will
cause less reliable/more restrictive proxies to poll less frequently.

Remove the parts that apply only to the Go code and get CI working on
the new directory structure.

This repository is for the web proxy only

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.