streams2: net.Socket stalls on large read()

Currently, if you attempt to perform a read() on a net.Socket for a buffer larger than
its highWaterMark the stream will stall.

This occurs because `onread()` in `lib/net.js` issues the `'readable'` event via its call
to `Readable.push()` prior to calling the underlying `readStop()` function.  This means
that the client will get the event, attempt another `read()` which is its one chance to
restart a stopped stream, and then the stream will be stopped.  The end result is a stall.

While it is possible to workaround this problem by setting the `highWaterMark` to the
size of the largest buffer you wish to read, not all net.Socket instances are created by
client code.  In particular, net.Socket objects returned by net.Server do not provide the
opportunity to set a `highWaterMark`.

This pull request provides a simple, albeit perhaps not ideal, solution.  When `read()`
is called on a Readable object with size parameter larger than the `highWaterMark`,
then automatically increase the `highWaterMark` to match.

An alternative would be to duplicate the `highWaterMark` logic in the net.Socket `onread()`
function so that the stream could be stopped prior to issuing the `'readable'` event
via the `push()` function.  This would then allow the client code to restart the stream by
calling `read()` again.

I'm interested to know if there are better or more correct ways to deal with this issue.

Thank you.