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:

use strict'

const { Readable } = require('stream')

const r = new Readable({
  read () {}
})

r.destroy()

async function run () {

  for await (let chunk of r) {
  }
}

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.