stream: read(0) should not always trigger _read(n,cb)

This is causing the CryptoStreams to get into an awful state when
there is a tight loop calling connection.write(chunk) waiting for
a false return.

Because CryptoStreams use read(0) to cycle data, this was causing
the encrypted side to pull way too much data in from the cleartext
side, since the read(0) would make it always call _read.

The unfortunate side effect, fixed in the next patch, is that
CryptoStreams don't automatically cycle when the Socket drains.

lib/_stream_readable.js

@@ -163,6 +163,16 @@ Readable.prototype.read = function(n) {
   if (typeof n !== 'number' || n > 0)
     state.emittedReadable = false;
 
+  // if we're doing read(0) to trigger a readable event, but we
+  // already have a bunch of data in the buffer, then just trigger
+  // the 'readable' event and move on.
+  if (n === 0 &&
+      state.needReadable &&
+      state.length >= state.highWaterMark) {
+    emitReadable(this);
+    return null;
+  }
+
   n = howMuchToRead(n, state);
 
   // if we've ended, and we're now clear, then finish it up.