refactor: remove abortable-iterator usage

[wemeetagain]

Closes #2001
Closes #2004
Closes #2020

[p-shahi]

Closing in favor of following this proposal: #1793

[wemeetagain]

This should be reopened since we decided against using web streams

[maschad]

This should be reopened since we decided against using web streams

I created a new issue to address this @wemeetagain

[marcus-pousette]

I wonder whether a

const abortTimeout = setTimout(()=>abort(), someTimeout);

// if thing performed did complete succesfully

clearTimeout(abortTimeout)

if success approach would be cleaner if you just want to abort stuff that has not succeeded in a specific timeout.

This is much clearer also than adding and removing functions from an EventEmitter AbortSignal

[achingbrain]

I wonder whether a [setTimeout] approach would be cleaner

We had something similar to this previously via timeout-abort-controller but ultimately we switched it out because AbortSignal.timeout is built in so doesn't require an extra dep, and it also has the nice property of not keeping the nodejs event loop running like setTimeout does.

There's a non-zero cost associated with spawning loads of setTimeouts, though it'd be worth measuring to see how it compares to the same number of AbortSignal.timeouts.