stream: fixes async iterator destroyed error propagation

[ronag]

There was an edge case where if _destroy calls the error callback
later than one tick the iterator would complete early and not
propgate the error.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[ronag]

ping @nodejs/streams bug?

[mcollina]

lgtm

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/28399/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/28411/

[Trott]

Landed in d15b8ea

[mcollina]

Please do not backport this PR. It's causing a regression on a very simple usage of the async iterator:

usestrict'
const{ Readable }=require('stream')constr=newReadable({read(){}})r.destroy()asyncfunctionrun(){forawait(letchunkofr){}}r.on('close',()=>{console.log('close emitted')run().then(()=>console.log('finished'))})

I'll issue a revert and add a test for it.

---

This is not easy to fix, as we do not have a 'closeEmitted' or 'destroyCompleted' status, so we cannot know if the destroy callback finished. Note that .destroyed is set syncrhonously. The problem is that we call finished() waiting for the callback to fire - and it never will.
Fixing this is likely semver-major, hence the coming revert.