This adds --quic-tls-cert and --quic-tls-key options to the server
(separate from --cert and --key); and a quic-tls-pubkey SOCKS arg (with
equivalent --quic-tls-pubkey command-line option) to the client.

This package defines how we encapsulate discrete discrete datagrams into
an HTTP request or response body, with optional padding.

https://bugs.torproject.org/29611#comment:6

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.