Remove//Improve UnconsAsync

[pchlupacek]

UnconsAsync is currently used by merge, prefetch and pause. Implementation of UnconsAsync is currently costly and every step requires non-negligible amount of work and allocations.
There is chance, that UnconsAsync can be removed and similar functionality implemented with already presented higher-level async._ combinators.

[mpilquist]

Interested to see what you've got here. If UnconsAsync were removed, that would likely impact API rather drastically (e.g., would AsyncPull be gone then too?). Or are you thinking we'd still have AsyncPull and ToPull#unconsAsync but we wouldn't implement that API with an UnconsAsync constructor?

[SystemFw]

I have similar thoughts. I'd definitely prefer unconsAsync be a normal combinator rather than a constructor, but removing its functionality altogether seems like a net decrease in expressiveness, maybe it's worth it though?
I do have to say I'm finding myself using merge less and less in favour of join for example, maybe someone can offer a counterargument in favour of "unconsAsync" style asynchrony/concurrency?

[pchlupacek]

Let me play with some ideas. I think I may have something sketched in few days. Not sure if I will make it till tomorrow, but will try. Current implementation of UnconsAsync sort of hurts the interruption, and I think we don't need that combinator. Perhaps I am wrong, but lets see. I just want to have at lest merge to work as fast as join (or nearly as) and have same interruption guarantees as join/concurrently.

[pchlupacek]

closed by #1066