https://bugs.torproject.org/29611

app.update.enabled doesn't exist anymore:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420514

This is copied from
projects/tor-browser/Bundle-Data/PTConfigs/meek-http-helper-user.js in
tor-browser-build.git commit 4792ed5246d389caad036290e9ed34ff0ae1f0ad.

The difference here is that we don't send a JSON error response as a
result of errors at this stage.

The native component actually doesn't need to introspect the objects it
passes to the browser, except for the "error" property of a response
when it wants to report its own error.

Re-use the catch handler.

This doesn't hurt, but we're still reliant on Firefox for using the
global "browser" object (instead of "chrome"), and especially for the
proxy code, which has a totally different API in Chrome.

A typo during debugging caused the callback to crash and have no effect.

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

Tor doesn't support this kind of proxy (https://bugs.torproject.org/26306),
but I want to support the same kinds of proxies with uTLS as are
supported using the native Go net/http, for ease of explaining the proxy
restrictions in the man page.

We use the same uTLS ClientHelloID for the TLS connection to the HTTPS
proxy, as we use for the TLS connection through the tunnel.