* Add separate SERVER_NODE_FLAGS envar
Since Meteor 0.5.3, Meteor allowed to pass node command line flags
to the server node process via the `NODE_OPTIONS` environment variable.
However, since Node version 8 / Meteor 1.6 this has become a default node
envar with the same behavior:
https://nodejs.org/api/cli.html#cli_node_options_options
The side effect is that this now also affects Meteor tool.
The command line parameters could already be set separately via the `TOOL_NODE_FLAGS` envar.
This is now also possible (again) for the server.
* Adds support to mongo options via Meteor settings
The options are in the `packages` key in the `mongo` key that is the package name. We should use the pattern every time we need a setting in a package.
Also specifying ecmascript and caching-compiler dependency versions
explicitly, since less is a non-core package, so the versions won't be
automatically determined during releases.
Follow-up to #10824.
If the preferred arch is not available (most likely because it was
deliberately excluded), it's better to use another client arch that is
available than to guarantee the site won't work by returning an unknown
arch. For example, if web.browser.legacy is excluded using the
--exclude-archs option (introduced by #10824), legacy clients are better
served by receiving web.browser (which might actually work) than receiving
an HTTP 404 response. If none of the arches in preferredArchOrder are
defined, only then should we send a 404.
SQLite has a worse-is-better philosophy about automatically converting
between different data types, such as strings and floating point numbers:
https://www.sqlite.org/quirks.html#flexible_typing
This means querying for the string "1.10" in a given column can return
rows where the column is actually the string "1.1", since SQLite imagines
you might be talking about the number 1.1, rather than the string you
actually requested.
This "feature" became a problem for Meteor after we published Meteor 1.10,
which caused SQLite to return multiple rows for the getReleaseVersion
query, including both Meteor 1.10 and Meteor 1.1 (which is ancient, from
March 2015).
While this behavior seems completely indefensible, the SQLite
documentation clearly does not consider it a bug, which forces us to work
around the consequences by double-checking the queried results with the
filterExactRows helper function.
