[root] add a return after handling ENOENT etc

Summary: Not a big deal, but something @dreiss spotted

Test Plan: `arc unit --everything`

Reviewers: wez

Reviewed By: wez

Subscribers: dreiss

Differential Revision: https://phabricator.fb.com/D1573416
perform reviews on our public phabricator instance
break out watchers in their own dirs

Summary:
As we've been threatening to do for quite some time, break up root.c a bit.

This is a relatively straightforward refactoring; breaks out the OS specific
watching interface code to source modules under the watcher dir.

I had to fix up a couple of build issues on FreeBSD where it got broken
by some NetBSD changes, and also to pass gmake through to the portions
of the test harness that assumed make.

Test Plan:
build and make integration on OS X, Linux, FreeBSD and
Illumos.

On FreeBSD, because I have a huge uid, I have to run like this:

`MAKE=gmake gmake ARFLAGS=cruD integration`

Reviewers: sid0

Reviewed By: sid0

Differential Revision: https://reviews.facebook.net/D28167
watchman: use launchd to spawn service

Summary:
we've seen a couple of cases where our mach connection to the
FSEvents service winds up in a broken state.  The theory is that this
is somehow related to the user logging out or from different security
contexts.

This diff hopes to avoid the issue by tying the user watchman process
to the GUI session of the user.

How it works: instead of daemonizing when we fail to connect to the
server socket, we construct a plist containing the invocation options
and place it in the user LaunchAgents directory, then request that
launchd load that plist.

We're asking launchd to manage the listening socket for us to handle
the case where the user issues a `watchman shutdown-server` command.
We do it this way because the process termination leaves the service
in a "waiting" state from the perspective of launchd; when in this
state, an attempt to load the plist again fails with an EAGAIN status.
By having launchd listen on the unix socket for us, it knows when to
trigger the watchman process and pass the descriptor over to it.

Once watchman has been successfully spawned via launchd for a user,
subsequent logins will load the plist at login time and cause launchd
to listen on the watchman unix socket, spawning watchman on demand.

If the user only ever logs in to their system using the GUI, what winds
up happening is that watchman will get shutdown when they log out of
the GUI and respawned on their next watchman query/request in their
next GUI login.

If the user logs in without a GUI running (eg: via ssh) and spawns
watchman, it will fall back to old fashioned daemonize to run the
server.  It will remain running even after the ssh session terminates.

If the user subsequently logs back in on the GUI, launchd will replace
the unix socket with its own, effectively orphaning the non-GUI server.
It would be great to have a way to detect when this happens.  Aside from
stranding the process, it doesn't harm the user experience with
watchman; they'll have a launchd spawned process that operates correctly
and that will get shut down when they log out.

Test Plan:
`make integration` still passes (it uses --foreground explicitly anyway).

In a GUI session:

`./watchman watch-list` writes out the plist and registers it with launchd.
`launchctl list | grep watchman` shows that it is registered
`ps -ef | grep watchman` shows a running watchman process with the
log, socket and state paths set explicitly (per the plist file)

Logging out of the GUI, logging in via SSH:

`pgrep watchman` shows no processes (it got shutdown on logout)

Logging back in to GUI:

`launchctl list | grep watchman` shows that it is registered
`pgrep watchman` shows no processes (nothing has triggered it to spawn yet)
`./watchman watch-list` spawns watchman and returns the watch list
`./watchman get-pid` and note it

Logging in via SSH while GUI is running:

`./watchman get-pid` shows the same pid as above; watchman continues to respond
as per normal.

Logging out of the GUI, then in the SSH session:

`pgrep watchman` shows no processes
`./watchman watch-list` tries to spawn watchman via launchd, reports an error (on stderr)
and falls back to daemonize, then responds with the watch list from its non-launchd invocation.

`ps -ef | grep watchman` shows a `watchman watch-list` with `init` as the parent.

Logging back in on a GUI:

`ps -ef | grep watchman` shows the `watchman watch-list` with `init` as the parent.
`./watchman watch-list` spawns a new watchman server via launchd, responds with expected results.
`ps -ef | grep watchman` shows both the launchd spawned instance and the init-parented server.

Logging out of the GUI, then in the SSH session:

`ps -ef | grep watchman` shows only the init-parented server
`./watchman watch-list` spawns a new init-parented server (because launchd orphaned the original unix socket)
`ps -ef | grep watchman` shows two init-parented servers

Reviewers: sid0

Reviewed By: sid0

Differential Revision: https://reviews.facebook.net/D28161
NetBSD before 6.99 uses BSD-style subsecond timespec.
Use configure to set if we are to use statvfs to get the fstype.
Update the CLA URL
travis: disable ruby

This appears to be a travis problem, but it is making our builds fail on
OSX.  Disable ruby tests.
watchman: fsevents: propagate errors from fsevents thread init

Summary:
We've seen a handful of issues where something goes bad with
the fsevents subsystem and the underlying watch is effectively broken
because it wasn't properly initialized.  This is exacerbated because
the failure is asynchronous with respect to watch establishment.

This diff synchronizes fsevents initialization with the rest of the
root initialization and adds a `failure_reason` to the root that can
be used to propagate an error message back from the other thread.

It also improves error handling for fsevents initialization failures.
Unfortunately there doesn't appear to be a way to capture the underlying
reason for the error from the library calls, so all we can do is
set the reason to the failing function.  The library calls do emit
a log line to the log file.

The watch command is augmented to inspect the `failure_reason` and
`cancelled` fields of the root and return an error.

Depends on D28167

Test Plan:
`make integration` shows that this works.

I injected a failure in fsevents initialization, then:

```
$ ./watchman watch .
{
    "version": "2.9.9",
    "error": "womp"
}
```

Previously, this would report the watch as successful and then (maybe) cancel it.

Reviewers: sid0

Reviewed By: sid0

Differential Revision: https://reviews.facebook.net/D28179
watchman: nodejs client bindings

Summary:
Adds a simple but powerful asynchronous binding to the watchman service.

My motivation is to allow consolidating watch resources between our
watchman-based source control and what I'm assuming is Grunt-based watching in
javascript (via gaze?).

The first step towards that is providing a client to talk to watchman and subscribe to changes.

Later steps are to look at having gaze or whichever node modules are most
heavily used in our workflows adapt to be able to consume the watchman based
watcher.

I've dabbled in nodejs in the past, but it's not my focus.  I'm looking for
suggestions on how to make this more idiomatic.  Obviously missing from this
diff is any kind of unit test.

Test Plan:
Manual:

```
cd watchman/node
npm install
npm link
npm link fb-watchman
node example.js
```

Outputs:

```
$ node example.js
Talking to watchman version 2.9.9
failed to subscribe:  { [Error: unknown command invalid-command-never-will-work]
  watchmanResponse:
   { version: '2.9.9',
     error: 'unknown command invalid-command-never-will-work' } }
subscription mysubscription established
/Users/wez/fb/watchman/node mysubscription [ { name: 'example.js',
    size: 1374,
    new: true,
    exists: true,
    mode: 33188 },
  { name: 'index.js',
    size: 3917,
    new: true,
    exists: true,
    mode: 33188 },
  { name: 'node_modules/json-stream/test/json-stream-test.js',
    size: 1539,
    new: true,
    exists: true,
    mode: 33188 },
  { name: 'node_modules/json-stream/test/pipe-test.js',
    size: 749,
    new: true,
    exists: true,
    mode: 33188 },
  { name: 'node_modules/json-stream/test/throw-in-readable-test.js',
    size: 305,
    new: true,
    exists: true,
    mode: 33188 },
  { name: 'node_modules/json-stream/lib/json-stream.js',
    size: 943,
    new: true,
    exists: true,
    mode: 33188 },
  { name: 'node_modules/nextback/test/main.js',
    size: 1224,
    new: true,
    exists: true,
    mode: 33188 },
  { name: 'node_modules/nextback/index.js',
    size: 229,
    new: true,
    exists: true,
    mode: 33188 } ]
```

Reviewers: amasad, sstur

Reviewed By: amasad, sstur

Subscribers: sstur, amasad

Differential Revision: https://reviews.facebook.net/D28203
Bump version number to 3.0.0

Since we tagged 2.9.9 we should stop claiming to be that version in
master.

Planning on tagging the 3.0.0 release this week.
refactor receive() code out of query() so it can be used with notifications

Summary:
this is a change to upstream third-party source, and should
be submitted for inclusion.

Test Plan: I have an application which uses this, and it works.

Reviewers: sid0, wez

Reviewed By: wez

Differential Revision: https://reviews.facebook.net/D28641
Merging upstream changes