Fix zipWith to work concurrently according to the stream type

[harendra-kumar]

trafficstars

zipWith and zipWithM currently work serially. They should instead work according to the stream type. For example, if the stream type is Async then they can zip multiple pairs concurrently out of order. For testing, one use case of this is mentioned in #100 .

The fix is simple, we need to use consM to build the stream, just like we do in concurrent mapM. We will just have to test it, that it works as expected.

cc @naushadh

[naushadh]

I suppose this is complementary to the existing zipAsyncWith?

[harendra-kumar]

zipAsyncWith makes sure that the actions from both the streams being zipped are executed concurrently, once it has the two items to zip, then it uses zipWith to zip the two items. So only one zip happens at a time. In case of ahead/async streams we can have multiple zips going on at the same time.

[harendra-kumar]

@adithyaov if this is fixed then you can close it.

[harendra-kumar]

Reopened by #1125, the commit was reverted by e09428332cb7a12effc52c5ad9c89dd6bcb36504.

[adithyaov]

We can possibly have zipConcurrentlyWithM for concurrent zipping. We should leave zipWith(M) alone as they break existing code.