Less restrictive DataSource effect implicits

Currently the methods that fetch data in DataSource require an effect type F with Par[F] and ConcurrentEffect[F].

Par is required due to the DataSource#batch implementation defaulting to running individual fetches in parallel. If we move away from it, Data sources that don’t implement batching will run their fetches sequentially. Par[F] will still be required when creating or running a fetch to F, since is used when running multiple batches in parallel.

ConcurrentEffect is perhaps too restrictive, since we may not need the cancellation semantics that Concurrent provides. We could use Effect here, thoughts?

[kubukoz]

Would you feel any different about Par if cats-par was officially endorsed by typelevel?

Here are all the reasons I found not to require Concurrent:

• it’s only used for a reimplementation of parTraverse for which Parallel/Par is enough
• it’s one of the most powerful type classes in the whole of cats/cats-effect: it provides ways to embed arbitrary side effects using FFI-like methods like delay, async, cancelable and friends; which is the main reason why it’s usually a good idea to use it sparingly and hide the details like calls to race behind algebras that’ll be implemented with Concurrent
• it requires Throwable errors, whereas the only place where Fetch catches and handles error is the run part (in which MonadError[F, Throwable] would probably suffice)
• very minor: you can have a Parallel for any monad, which gives the ability to get a class under test with a simple type like Id or Either and not a full blown IO that may or may not consist of asynchronous blocks

FYI ContextShift is completely unused in the code for fetch, too, so the only thing that remains is Clock, usage of which could be superseded by a custom algebra for measuring time (allowing custom implementations that’d simply return a dumb value for tests).

[peterneyens]

I think Par is worth having to avoid having to duplicate its implementation for types that have Concurrent.

I think I disagree know with what I said almost 6 months ago as well, and I agree that we should look if we can’t get by with just Concurrent (instead of ConcurrentEffect).