Rather than aborting in the face of *any* repeated link in a given path,
instead only abort if such a cycle actually makes a given path unresolvable.

Test for this by doing a normal stat.  Still use the seenLinks object to
cache link contents so as to cut own a little bit on readlink calls.

Also add a pathological test that fails without the change to fs.js.

Implementing a tip from Marc Lehmann:
http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#The_special_problem_of_accept_ing_wh

Keep an extra FD around for every server. When you hit EMFILE, destroy that
FD, accept a connection, close it; in this way you can clear the connection
queue and let people know that you're overload.

No more timeout needed.

Users too often would forget to add

  socket.on('end', function () {
    socket.end();
  });

Which is a mistake. Therefore we default to this behavior and
only optionally let people handle the 'end' case themselves.

and add more debug() calls to make it easier to see the flow

and add a start method, to kick off SSL handshaking, without writing a zero
byte buffer

also affects dgram which uses a constant from node_net.cc

Already tested in test/simple/test-buffer.js. Takes too long, uses too much
memory.

This reverts commit 8c0e87f9.

(Revert until fix comes)

in
test-net-timeout
test-http-client-parse-error

When a server hit EMFILE it would continue to try to accept new connections
from the queue. This patch introduces a timeout of one second where it will
stop trying to accept new files. After the second is over it tries again.

This is a rather serious bug that has been effecting many highly concurrent
programs. It was introduced in 4593c0, version v0.2.0.

TODO: A test for this situation. Currently I test it like this

  termA% cd projects/node
  termA% ulimit -n 256
  termA% ./node benchmark/idle_server.js

  termB% cd projects/node
  termB% ./node benchmark/idle_clients.js

And watch how the server process behaves.

Also default to SIGTERM for destruction when exceeding timeout or buffer on
exec()