* uv: Upgrade to 1.4.2

* npm: Upgrade to 2.7.4

* V8: do not add extra newline in log file (Julien Gilli)

* V8: Fix --max_old_space_size=4096 integer overflow (Andrei Sedoi)

* asyncwrap: fix constructor condition for early ret (Trevor Norris)

* buffer: align chunks on 8-byte boundary (Fedor Indutny)

* buffer: fix pool offset adjustment (Trevor Norris)

* build: fix use of strict aliasing (Trevor Norris)

* console: allow Object.prototype fields as labels (Colin Ihrig)

* fs: make F_OK/R_OK/W_OK/X_OK not writable (Jackson Tian)

* fs: properly handle fd passed to truncate() (Bruno Jouhier)

* http: fix assert on data/end after socket error (Fedor Indutny)

* lib: fix max size check in Buffer constructor (Ben Noordhuis)

* lib: fix stdio/ipc sync i/o regression (Ben Noordhuis)

* module: replace NativeModule.require (Herbert Vojčík)

* net: allow port 0 in connect() (cjihrig)

* net: unref timer in parent sockets (Fedor Indutny)

* path: refactor for performance and consistency (Nathan Woltman)

* smalloc: extend user API (Trevor Norris)

* src: fix for SIGINT crash on FreeBSD (Fedor Indutny)

* src: fix builtin modules failing with --use-strict (Julien Gilli)

* watchdog: fix timeout for early polling return (Saúl Ibarra Corretgé)

In Linux, simple/test-child-process-fork-net2.js fails intermittently.

In SuSE Linux system, under network high load situations, this failure is
consistently reproducible.

The test case tests whether the TCP connections which were established between
the processes terminate in a timely and clean manner. After some iterations of
data transfer on established connections, the server is closed. The server does
not get closed immediately, instead waits for all the active connections to
terminate. A timed (200ms) callback closes the connections, which eventually
closes the server.

The start is the time when the server close is invoked.
The end is the time when the server is actually closed(onClose call back invoked).

Given that there is a minimum delay of 200ms before the connections are
terminated, expecting the elapsed time above 190 is reasonable and fair,
but looks like the leeway of 800ms for the upper bounds seem to be too
stringent, and breaking some scenarios of network load.

Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
PR-URL: #14129