incorrectly handling live aborts #2
Description
there is an edgecase in aborts which this does not handle correctly.
in early versions of pull-streams, you could only abort when you would do a read,
which generally worked, but sometimes a read may stall indefinitely,
say, you are waiting for a real time resource, that happens not to do anything for a long time.
Example, reading lines added to a log file (like, tail -f) except nothing gets written.
in that case, you need to call abort before the previous read has called back,
so, an abort while isResolving=true is okay, but never 2 calls,
and then the previous read should callback first, then the abort call.