Between `ClientRequest` and `Agent`. The circular require was doing
weird things at load time, like making the `globalAgent` property
be `undefined` from within the context of the "_http_client"
module.

Removing the circular dependency completely fixes this.

This commit effectively removes the undocumented `Agent#request()`
and `Agent#get()` functions.

Don't invoke the `agent.requst()` or `agent.get()` functions
directly. Instead, use the public API and pass the agent
instance in as the `agent` option.

For the `request()` and `get()` functions. I could never
really understand why these two functions go through agent
first... Especially since the user could be passing `agent: false`
or a different Agent instance completely, in which `globalAgent`
will be completely bypassed.

Moved the relevant logic from `Agent#request()` into the
`ClientRequest` constructor.

Incidentally, this commit fixes #7012 (which was the original
intent of this commit).

See #7012.

Rely on defined order of operations by closing the server and
destorying the client socket, instead of when setImmediate fires

Expose `setBlocking` on Pipe's and if a pipe is being created for stdio
on windows then make the pipes blocking.

This fixes test-stream2-stderr-sync.js on Windows.

Fixes #3584

One test case in test-stream2-stderr-sync.js was creating a TTY
object using an undocumented constructor and passing in fd 2.
However, this is running in a child process and fd 2 is actually
a pipe, not a TTY.

The constructor fails on Windows and causes the handle type to be
left uninitialized, which later causes an assert to fail.

On Unix, the constructor fails to retrieve the windows size but unlike
on Windows, it just leaves the size fields undefined and continues
with initializing the stream type, yielding a semi-usable object.

I could make the Windows version match Unix behavior, but it
seems to me that the test is relying on an implementation detail of
an undocumented API, and the Unix behavior is not necessarily more
correct than the Windows one. Thus it makes more sense to remove this
test.

NodeBIO::Gets was reading off the end of a buffer if it
didn't find a "\n" before the EOF.  This behavior
was causing X509 certificates passed to `https.Agent`
via the "ca" option to be silently discarded. It also
was causing improper parsing of certs and keys
passed to https.Agent, but those problems were worked
around in cdde9a38.

Backed out workaround in `lib/crypto.js` from ccde9a3,
which now isn't needed.  But keep the test introduced
in that commit, which tests properly for this
bug.

This bug was first introduced in a58f93f

Gist containing test code, bisection log, and notes:
   https://gist.github.com/maxtaco/9211605

The linker was optimizing the static variables that were supposed
to trigger module initialization.

I am making them non-static, and dllexport so that they don't get
optimized away.

Fixes #7116

Fix a bug introduced by 3da36fe0 of a missed early return of a handle
that needed to be passed to listen.

Fixes test-net-listen-fd0.js on Windows

This ends up being too difficult to test across different deployments

We were trying too hard to connect, and getting timeouts instead of
the refusals, slow down how hard we try.

When calling out to the openssl client handle the child closing and
returning EPIPE on writes

ESERVFAIL is also an acceptable error code when failing to resolve a
domain.

This test is particularly pathological, and requires a ton of time to
run, we need to find a better way to manage it but in general this path
is fairly safe these days.

bufferSize is now a getter that shows all that has not been
acknowledged by the os, as well as in the buffer state. The test is
only looking to verify the js verified state.

watch file will now generate an empty event when the file doesn't exist
initially

Scheduling of next ticks from within the next tick handler will result
in a tight execution loop where a timer cannot break into.

This test was invalid

Environment doesn't have ThrowException, we meant isolate here.

Introduced in commit
75adde07.

We were being very aggressive in our connection creations, resulting
in the pipeline flood detection to drop us. Relax how fast we're
creating these connections so the gc can run all its tests.

fix #6899

It wasn't doing anything, and actually due to
3ae0b17c, it was causing
the readline `prompt()` function to be overwritten
which throws an error in the REPL shortly after.

Use setHeader in writeHead to avoid sending duplicate headers

Fixes #5036

Conflicts:
	AUTHORS
	ChangeLog
	deps/uv/AUTHORS
	deps/uv/ChangeLog
	deps/uv/build.mk
	deps/uv/src/unix/linux-core.c
	deps/uv/src/unix/stream.c
	deps/uv/src/unix/sunos.c
	deps/uv/src/version.c
	src/node_version.h

This were accidentally moved during the website refactor

* uv: Upgrade to v0.10.25 (Timothy J Fontaine)

* npm: upgrade to 1.4.3 (isaacs)

* v8: support compiling with VS2013 (Fedor Indutny)

* cares: backport TXT parsing fix (Fedor Indutny)

* crypto: throw on SignFinal failure (Fedor Indutny)

* crypto: update root certificates (Ben Noordhuis)

* debugger: Fix breakpoint not showing after restart (Farid Neshat)

* fs: make unwatchFile() insensitive to path (iamdoron)

* net: do not re-emit stream errors (Fedor Indutny)

* net: make Socket destroy() re-entrance safe (Jun Ma)

* net: reset `endEmitted` on reconnect (Fedor Indutny)

* node: do not close stdio implicitly (Fedor Indutny)

* zlib: avoid assertion in close (Fedor Indutny)

Makes clear that the behaviour of stdout is blocking
in Linux/Unix even when they refer to pipes.