* v8: back-port fix for CVE-2013-2882

* npm: Upgrade to 1.3.8

* crypto: fix assert() on malformed hex input (Ben Noordhuis)

* crypto: fix memory leak in randomBytes() error path (Ben Noordhuis)

* events: fix memory leak, don't leak event names (Ben Noordhuis)

* http: Handle hex/base64 encodings properly (isaacs)

* http: improve chunked res.write(buf) performance (Ben Noordhuis)

* stream: Fix double pipe error emit (Eran Hammer)

This is the conceptual back-port of commit ec548734 from the master
branch.

This is a backport of 6d3d60aced39d59eaa5e705b7d822c227d0d3dae for
v0.10.

If an error listener is added to a stream using once() before it is
piped, it is invoked and removed during pipe() but before pipe() sees it
which causes it to be emitted again.

Fixes #4155 #4978

Quoting the CVE:

    Google V8, as used in Google Chrome before 28.0.1500.95, allows
    remote attackers to cause a denial of service or possibly have
    unspecified other impact via vectors that leverage "type confusion."

Likely has zero impact on node.js because it only runs local, trusted
code but let's apply it anyway.

This is a back-port of upstream commit r15665. Original commit log:

    Use internal array as API function cache.

    R=yangguo@chromium.org
    BUG=chromium:260106
    TEST=cctest/test-api/Regress260106

    Review URL: https://codereview.chromium.org/19159003

Fixes #5973.

Adds the documentation requested in #5017.

Flags and modes aren't the same, symlinks are followed in all of the
path but the last component, docs should say something about what the
mode argument is for and when its used, fs.openSync should point to the
function that contains the docs for its args, as fs.writeSync does.

Run the garbage collector before running the actual test. It doesn't
matter now but if in the future something in node.js core creates a lot
of reclaimable garbage, that will break the test's expectation.

* Run the garbage collector before creating the big array. It doesn't
  matter now but if in the future something in node.js core creates
  a lot of reclaimable garbage, that will break the test's expectation.

* The first RSS check was being done too late. The garbage collector
  might have run before the check, throwing off the 'reclaimed memory'
  calculation.

* Due to changes in how V8 represents the big array internally, the
  actual memory usage is just below 256 MB on x64. Update the test's
  expectation.

Before this commit, events were set to undefined rather than deleted
from the EventEmitter's backing dictionary for performance reasons:
`delete obj.key` causes a transition of the dictionary's hidden class
and that can be costly.

Unfortunately, that introduces a memory leak when many events are added
and then removed again. The strings containing the event names are never
reclaimed by the garbage collector because they remain part of the
dictionary.

That's why this commit makes EventEmitter delete events again. This
effectively reverts commit 0397223a.

Fixes #5970.

Avoid a costly buffer-to-string operation. Instead, allocate a new
buffer, copy the chunk header and data into it and send that.

The speed difference is negligible on small payloads but it really
shines with larger (10+ kB) chunks. benchmark/http/end-vs-write-end
with 64 kB chunks gives 45-50% higher throughput. With 1 MB chunks,
the difference is a staggering 590%.

Of course, YMMV will vary with real workloads and networks but this
commit should have a positive impact on CPU and memory consumption.

Big kudos to Wyatt Preul (@wpreul) for reporting the issue and providing
the initial patch.

Fixes #5941 and #5944.

Use the StringBytes::IsValidString() function introduced in commit
dce26cce to ensure that the input string meets the expectations of the
other StringBytes functions before processing it further.

Fixes the following assertion:

    Assertion failed: (str->Length() % 2 == 0 && "invalid hex string
    length"), function StorageSize, file ../../src/string_bytes.cc,
    line 301.

Fixes #5725.

Performs a quick, non-exhaustive check on the input string to see if
it's compatible with the specified string encoding.

Curently it only checks that hex strings have a length that is a
multiple of two.

The title shouldn't be too long; libuv's uv_set_process_title() out of
security considerations no longer overwrites envp, only argv, so the
maximum title length is possibly quite short.

Fixes #5908.

* src: fix process.getuid() return value (Ben Noordhuis)

And process.getgid() too.

Commit ed806385 changed fs.chown() and fs.fchown() to only accept
unsigned integers. Make process.getuid() and process.getgid() follow
suit.

This commit should unbreak npm on OS X - it's hitting the new 'uid must
be an unsigned int' check when installing as e.g. user 'nobody' (which
has an UID of -2 in /etc/passwd or 4294967294 when cast to an uid_t.)

Fixes #5904.

* uv: Upgrade to v0.10.13

* npm: Upgrade to v1.3.5

* os: Don't report negative times in cpu info (Ben Noordhuis)

* fs: Handle large UID and GID (Ben Noordhuis)

* url: Fix edge-case when protocol is non-lowercase (Shuan Wang)

* doc: Streams API Doc Rewrite (isaacs)

* node: call MakeDomainCallback in all domain cases (Trevor Norris)

* crypto: fix memory leak in LoadPKCS12 (Fedor Indutny)

The return values from uv_cpu_info() don't necessarily fit in a 32 bits
signed integer.

Fixes #5732.

Before this commit, fs.chown() and fs.fchown() coerced the uid and gid
arguments to signed integers which is wrong because uid_t and gid_t are
unsigned on most all platforms and IDs that don't fit in a signed
integer do exist.

This commit changes the aforementioned functions to take unsigned ints
instead.  No test because we can't assume the system has [GU]IDs that
large.

This change depends on joyent/libuv@d779eb5.

Fixes #5890.