This way, we still exit when the parent process dies, even if for
whatever reason Firefox doesn't give us a helper address.

https://bugs.torproject.org/29559

It'll never exceed math.MaxUint32 if you convert it to uint32 first... I
didn't notice what nonsense this was until I saw the commit email.

len returns int, which is specified to be either 32 or 64 bits, so it
will never be truncated when coverting to uint64.
https://golang.org/ref/spec#Numeric_types

The WebExtension needs a JSON "host manifest" that both authorizes the
extension to run a native executable, and tells the browser where to
find the native executable. The path inside the manifest needs to be an
absolute path, so we cannot just plunk down a static file; we have to
know the path to where the browser is installed. meek-client-torbrowser
rewrites the manifest on each startup, where the browser expects to find
it.

The is mostly self-contained and compatible with previous behavior, with
one small exception on windows. On mac and linux, the browser expects to
find the manifest in a well-known location (relative to $HOME, which in
our case is inside the browser's directory tree or the ancillary
TorBrowser-Data directory). But on windows, the path to the manifest
needs to be stored in the registry. So meek-client-torbrowser not only
writes the manifest file, it also writes a registry key pointing to the
file. I'd like to try and find a way to do this that doesn't require
modifying global state like this.

This patch is tested on linux and windows but not mac.

This is what enabled me to find the proxyDNS problem fixed by the
previous commit. Without it, there was no error message in the browser
console.

This is to work around a Firefox patch that otherwise prevents DNS
requests from being made when proxyType=="direct".

Compare to
https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=32ca07ca008f5d09492f4d2782130bd54c52acf5

Object.fromEntries is not available until 63:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/fromEntries#Browser_compatibility

The --help output no longer mentions --invisible. About --headless it
says:
  --headless         Run without a GUI.

Also use double dashes in --no-remote and --profile, to match --help
output.

It turns out that if an error occurs in proxy.onRequest, Firefox will
ignore it and continue on as if there were no proxy. This can happen,
for example, if the "type" of a ProxyInfo isn't one of the recognized
types, or if the ProxyInfo is missing a field like "host".
https://bugzilla.mozilla.org/show_bug.cgi?id=1528873
To prevent silent failures like this, we register another pair of event
listeners. Unlike the headers and proxy event listeners, these remain
static for all requests, and are not overwritten with each new request:
 * proxy.onError detects when an error occurs.
 * webRequest.onBeforeRequest cancels all requests after an error
I made the error condition be persistent because it's not something that
should arise during normal operation. proxy.onError only gets called
when an error occurs in proxy.onRequest, and that only happens when the
proxy specification is bogus. It doesn't get called when there's an
network error, for example.

In order to make exceptions in proxy.onRequest be noticed by
proxy.onError, I had to make it return a rejection promise rather than
throw an exception. An exception just gets logged to the browser console
and nothing else.

Just like with headers, we can only control the proxy through a global
event listener, namely proxy.onRequest. We use the same scheme of
locking modifications to the events so that only one request at a time
is affected.

In handleConn, take any error that roundTrip produces, and wrap it in a
responseSpec that has an Error member set. This allows us to return an
error object back to meek-client in cases like this:
	$ printf '\x00\x00\x00\x44{"method":"POST","url":"https://meek.bamsoftware.com/","body":"abc"}' | ncat 127.0.0.1 1234
	→ \x00\x00\x00\x2f{"error":"illegal base64 data at input byte 0"}
In this way, we separate errors that occur during the roundtrip from
errors that occur while writing the response back to the socker.

These are:
	Accept
	Accept-Language
	Cookie
	Origin
	User-Agent

Cf. https://bugs.torproject.org/12778

In the old extension we stripped *all* headers, except for
Content-Length and Content-Type, which got set by
nsIUploadChannel.setUploadStream; and Connection, which somehow
automatically got the value "keep-alive".
https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=0e6ced86880b54f57a80b34d7f1b32a0eaa33b48

In the new WebExtension, stripping all headers really strips them all,
including Content-Length, without which web servers may refuse to deal
with us. So instead, just delete an enumerated list of headers that seem
unnecessary; or, like Cookie or Origin, may enable cross-session
tracking.

Before this change (url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com):
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 0
Host: meek.azureedge.net
Origin: moz-extension://3b29e17d-f486-48b9-8a03-782237114ad3
Pragma: no-cache
TE: Trailers
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
X-Session-Id: QE9IrvZFtFc

After this change:
Accept-Encoding: gzip, deflate, br
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 0
Host: meek.azureedge.net
Pragma: no-cache
TE: Trailers
X-Session-Id: CKOaxq4SVqM

The fetch API itself doesn't let you change certain headers, notably
including Host which we need for domain fronting. So instead, we set an
onBeforeSendHeaders listener, with a lock to cause this shared global
setting to be used by only one request at a time.

roundtrip doesn't need to know the ID; tack that on in the onMessage
listener.

cache: "no-store"
credentials: "omit"
redirect: "manual"

cache: "no-store" adds these headers, which seem fine:
Cache-Control: no-cache
Pragma: no-cache

Doesn't yet:
 * allow control of the Host header (domain fronting)
 * support a proxy

Since 0ec986eb. This is the case with
all pluggable transports now.

It causes an error when it uses something unsupported, like
username:password.

This was a regression added in 3fe68658.

socks5 since go1.9:
https://golang.org/doc/go1.9#net/http
https://github.com/golang/go/issues/18508
https://github.com/golang/go/commit/36f55a8b6125c9ae951487a0ad074b5c991f7b92

https since go1.10:
https://golang.org/doc/go1.10#net/http
https://github.com/golang/go/issues/11332
https://github.com/golang/go/commit/f5cd3868d52babd106e0509a67295690246a5252

As opposed to url= and front= SOCKS args.