proactively remove use of the _events object

[calvinmetcalf]

nodejs/node#5127 is a planed breaking change that we will likely need to fix in readable-stream before they can land it in core

[sonewman]

sorry, extremely delayed response. do you have any suggestions?

[mcollina]

So, we are using _events only on one point: https://github.com/nodejs/readable-stream/blob/master/lib/_stream_readable.js#L609-L616. Also, this is present on core as well: https://github.com/nodejs/node/blob/92212014ffc95a8bc5e56fcc2c076bac63c20c23/lib/_stream_readable.js#L561-L568

I think the fix is more complicated: we need that functionality, and we will need to backport the change to the 1.x line (at least) to work on most-recent nodes.

I propose that:

1. we fix it in core
2. we backport the fix to the v2 line
3. we backport the fix to the v1 line

I see two options: the first is to add another method to EventEmitter onFirst, that we can add an event at the top of the list. I don't like this very much, as we will not be fixing the issue.
I propose we use another mechanism (not the 'error' event) to make the piping stop: what we want is dest to call unpipe in case of errors, not the other way around.

The most important problem is the impact and amount of breakages it will have on the community.

[mcollina]

Relevant to the discussion: nodejs/node#6032

[mcollina]

So, nodejs/node#6032 is about to land. The question is: should we backport the fix to v1.0 and v1.1, or we will implement it only in v2? We would probably need this fix when nodejs/node#5127 lands (likely for v7).

I'm leaning towards deprecating v1 and v1.1 lines as proposed in #201 when 6 comes out, with a link pointing somewhere and explain why things will stop working on node v7 but are fine in node v6.

@rvagg what do you think?