zlib: don't assert on missing dictionary

Handle Z_NEED_DICT errors graciously. Fixes the following assertion:

  node: ../src/node_zlib.cc:161: static void node::ZCtx::Process
  (uv_work_t*): Assertion`ctx->dictionary_ != __null && "Stream
  has no dictionary"' failed.
  Aborted (core dumped)

Fixes #4632.
zlib: don't assert on malformed dictionary

Handle Z_DATA_ERROR errors from inflateSetDictionary() gracefully.
Fixes the following assertion:

  node: ../src/node_zlib.cc:167: static void node::ZCtx::Process
  (uv_work_t*): Assertion `ctx->err_ == 0 && "Failed to set
  dictionary"' failed.
  Aborted (core dumped)

Fixes #4632.
doc: document PYTHON env var in README
blog: Post for v0.9.8
doc: fix typo in crypto Hash.digest() note

Added the word 'has' to the sentence.
Closes #4652.
benchmark: Port http.sh from master
buffer: slow buffer copy compatibility fix

Fix issue where SlowBuffers couldn't be passed as target to Buffer
copy().

Also included checks to see if Argument parameters are defined before
assigning their values. This offered ~3x's performance gain.

Backport of 16bbecc from master branch. Closes #4633.
doc: fix typo in cluster module documentation

Fix a small typo in the cluster.settings documentation.
deps: upgrade libuv to 034ea31
blog: Correct shasums for v0.9.8 release
doc: don't suggest to reuse net.Socket objects

Using Socket.prototype.connect() to reconnect an existing Socket object
is not reliable. Users should just create a new Socket object.

See #4698.
zlib: reduce memory consumption, release early

In zlibBuffer(), don't wait for the garbage collector to reclaim the zlib memory
but release it manually. Reduces memory consumption by a factor of 10 or more
with some workloads.

Test case:

  function f() {
    require('zlib').deflate('xxx', g);
  }
  function g() {
    setTimeout(f, 5);
  }
  f();

Observe RSS memory usage with and without this commit. After 10,000 iterations,
RSS stabilizes at ~35 MB with this commit. Without, RSS is over 300 MB and keeps
growing.

Cause: whenever the JS object heap hits the high-water mark, the V8 GC sweeps
it clean, then tries to grow it in order to avoid more sweeps in the near
future. Rule of thumb: the bigger the JS heap, the lazier the GC can be.

A side effect of a bigger heap is that objects now live longer. This is harmless
in general but it affects zlib context objects because those are tied to large
buffers that live outside the JS heap, on the order of 16K per context object.

Ergo, don't wait for the GC to reclaim the memory - it may take a long time.

Fixes #4172.
zlib: pass object size hint to V8

Inform V8 that the zlib context object is tied to a large off-heap buffer.

This makes the GC run more often (in theory) and improves the accuracy of
--trace_external_memory.
blog: remove dangling symlink

Fixes #4716.
stream: make Writable#end() accept a callback function

This is more backwards-compatible with stream1 streams like `fs.WriteStream`
which would allow a callback function to be passed in as the only argument.

Closes #4719.
v8: loosen artificial mmap constraint

Fixes #4010.
typed arrays: only share ArrayBuffer backing store

Follow browser behavior, only share the backing store when it's a
ArrayBuffer. That is:

  var abuf = new ArrayBuffer(32);
  var a = new Int8Array(abuf);
  var b = new Int8Array(abuf);
  a[0] = 0;
  b[0] = 1;
  assert(a[0] === b[0]);  // a and b share memory

But:

  var a = new Int8Array(32);
  var b = new Int8Array(a);
  a[0] = 0;
  b[0] = 1;
  assert(a[0] !== b[0]);  // a and b don't share memory

The typed arrays spec allows both `a[0] === b[0]` and `a[0] !=== b[0]`
but Chrome and Firefox implement the behavior where memory is not
shared.

Copying the memory is less efficient but let's do it anyway for the
sake of the Principle of Least Surprise.

Fixes #4714.
test: add cluster EADDRINUSE test

Check that having a worker bind to a port that's already taken doesn't
leave the master process in a confused state. Releasing the port and
trying again should Just Work[TM].
streams: both `finish` and `close` should unpipe

Otherwise sockets that are 'finish'ed won't be unpiped and `writing to
ended stream` error will arise.

This might sound unrealistic, but it happens in net.js. When
`socket.allowHalfOpen === false`, EOF will cause `.destroySoon()` call which
ends the writable side of net.Socket.
npm: Upgrade to v1.2.10