stream: Avoid nextTick warning filling read buffer

In the function that pre-emptively fills the Readable queue, it relies
on a recursion through:

stream.push(chunk) ->
maybeReadMore(stream, state) ->
  if (not reading more and < hwm) stream.read(0) ->
stream._read() ->
stream.push(chunk) -> repeat.

Since this was only calling read() a single time, and then relying on a
future nextTick to collect more data, it ends up causing a nextTick
recursion error (and potentially a RangeError, even) if you have a very
high highWaterMark, and are getting very small chunks pushed
synchronously in _read (as happens with TLS, or many simple test
streams).

This change implements a new approach, so that read(0) is called
repeatedly as long as it is effective (that is, the length keeps
increasing), and thus quickly fills up the buffer for streams such as
these, without any stacks overflowing.
stream: Don't emit 'end' unless read() called

This solves the problem of calling `readable.pipe(writable)` after the
readable stream has already emitted 'end', as often is the case when
writing simple HTTP proxies.

The spirit of streams2 is that things will work properly, even if you
don't set them up right away on the first tick.

This approach breaks down, however, because pipe()ing from an ended
readable will just do nothing.  No more data will ever arrive, and the
writable will hang open forever never being ended.

However, that does not solve the case of adding a `on('end')` listener
after the stream has received the EOF chunk, if it was the first chunk
received (and thus, length was 0, and 'end' got emitted).  So, with
this, we defer the 'end' event emission until the read() function is
called.

Also, in pipe(), if the source has emitted 'end' already, we call the
cleanup/onend function on nextTick.  Piping from an already-ended stream
is thus the same as piping from a stream that is in the process of
ending.

Updates many tests that were relying on 'end' coming immediately, even
though they never read() from the req.

Fix #4942