disaster
perhaps this comment is less useful now
replicated
More debugging support and run the benchmarky test with a real cost function
Add a few comments
Clean up branch for merge

Disable new test until we “fix” it (make it break)
Merge branch 'constraint-explorer' into devel
Move benchmark tests to own file, add comments
Pre-convert all constraints
Remove or translate all “numbers” besides a.b.c

in test-data.  Importantly, tests still pass!

For example:
- Convert 1.2 to 1.2.0
- Convert 1.2.0.0 to 1.2.0
- Remove 1.2.0.1 completely
- Remove all rcs, betas, alphas, pres, etc.

Remove unused “platform” property.

Next step: Make the test not depend on setting ECVs in order to pass.
Revert accidental committal of client test-data

Client should not get test-data right now; that was just for debugging.
Simulate non-semver `>=` using alternations

The original benchmark/test translated all constraints into either inexact or exact Meteor constraints — that is, Rails’s `~>1.2.3`, `>1.2.3`, and `>=1.2.3` became the inexact `1.2.3`, and `=1.2.3` became `=1.2.3` — but also gave all versions of all packages an ECV of 0.0.0, meaning all versions are compatible with each other.

In order to make this test pass without ECV, we need to emulate pure `>=` (without incompatibility between major versions) in some other way.  So, for each constraint of the form `foo@a.b.c` where `foo` has larger major versions available than `a`, we allow those major versions as well.  For example, if we depend on `foo@1.1.11` and the largest version of `foo` is `3.2.0`, we rewrite `1.1.11` to `1.1.11 || 2.0.0 || 3.0.0` in order to emulate a pure `>=1.1.11` with no concern for major version compatibility.
Merge branch 'devel' into fix-gems-benchmark

Conflicts:
	packages/constraint-solver/constraint-solver-tests.js
Remove unnecessary code in benchmark tests
Merge branch 'fix-gems-benchmark' into devel

The larger, "benchmark" tests of the constraint solver broke when we
got rid of ECVs earlier this week, because they relied on setting the
ECV to get certain package version semantics.  (We didn't notice they
were broken because these slow tests aren't run unless you ask for
them explicitly via an environment variable.)

This branch fixes up the data to behave equivalently but without
relying on ECVs.  It also removes code that post-processes the dataset
by baking the processing into the data itself.  This is appropriate,
because we ought to be able to specify constraint solver tests in a
simple input-data-output-data sort of way.
Comment more about benchmark data
Remove unnecessary parts of Catalog stubs
Add a simple test around build IDS
Implement utils.coalesce(delayMs, callback).
Use fs.watch again for more efficient change detection.

Summary:
The idea of using `fs.watch` instead of `fs.watchFile` has been appealing
ever since we removed the original (buggy) implementation, because file
system events are a much more efficient way to detect changes to the file
system, compared with the polling strategy used by `fs.watchFile`.

There are several major drawbacks to `fs.watch`, however.

First, the `fs.watch` API is inconsistent across platforms. On different
systems, different sequences of events can be emitted in rapid succession,
depending on how the file system decides to represent changes. On OS X the
name of the changed file is not even passed to the callback.

Second, the number of files that can be watched simultaneously, while
relatively high on modern machines, is dangerously within the range of a
project like Meteor.

Third, `fs.watch` cannot be used to watch for changes to files or
directories that do not yet exist. By contrast, `fs.watchFile` has no
trouble polling for non-existent files.

This commit solves these problems by

1. watching only directories, using directory change events as a cue to
   trigger file change events, which has the benefit of reducing the total
   number of simultaneous watches, since there are far fewer directories
   than the total number of files,

2. coalescing directory change events so that only the last event in a
   rapid succession of events actually triggers inspection of the
   directory's contents, and

3. falling back to watching the parent directory if a given file or
   directory does not exist, so that once the file and the intermediate
   directories are created, the corresponding change events will be fired,
   achieving semantics similar to those of `fs.watchFile` without polling.

While I have run this code and verified that it eliminates high CPU usage
and handles file changes correctly, it would definitely be great to add
some tests to prevent regressions.

Fixes #2135.

Test Plan: `meteor run` and try adding/changing/removing files/directories

Reviewers: glasser

CC: nim

Differential Revision: https://phabricator.meteor.com/D922