Fs2: Decide the fate of Task

[mpilquist]

cats.effect.IO is equivalent to fs2.Task with a bunch of improvements, including a smaller, more consistent API.

If fs2.Task lives on in 1.0, it should provide significant utility over that provided by cats.effect.IO -- I don't want users to have to pick between two mostly equivalent types. For instance, the Monix Task adds cancellation, concurrency, and a much different execution strategy.

Reminder: if we decide to keep Task, we'll need to increase the test coverage. The type itself has almost no tests and all uses of it in the stream specs were replaced with IO.

[pchlupacek]

@mpilquist I was thinking about this more and I think we really have to decide between:

1. Keep fs2 separate from cats, its dependencies etc, and eventually having to build and maintain fs2-cats, that will add all necessary cats boilerplate, including first class support for c.e.IO

2. Make fs2 dependent on cats and then remove Task.

I don't see any middle paths that will add long term benefits to users. I.e. depending on cats, but having own effect type seems silly to me and not practical (we would take this dependency over just for very few MonadError instances that we need).

So if there will be any necessity to have specific changes that is not yet in c.e.IO, I think we have to make them in IO.

Given current state of affairs, and already that much work you put having fs2 to depend on cats, I think we really have only option (2) left.

[mpilquist]

IO is working great in the 1.0 branches so let's drop task in favor of IO.

[pchlupacek]

:-) ok