Polysemy concurrency effect

[isovector]

This PR adds a Concurrency effect to polysemy-wire-zoo, which lifts behavior from unliftio for splitting up tasks over multiple threads. In general, this is unsafe in application code and polysemy doesn't handle it very well, and in most cases it is going to create surprising bugs if it's used in application code.

That being said, there are "safe" usages of Concurrency where the only actions being lifted are IO, which is something interpreters can guarantee. The Concurrency effect tracks enforces this safety constraint at the type level.

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

[isovector]

@mdimjasevic

[mdimjasevic]

Thanks for this!

I just have one tiny comment in a sequential interpreter, but even if my comment is valid, I think we can do that in a follow-up PR to fix it.

[mdimjasevic]

Should this have been 'Safe instead of safe in the type :: Sem (Concurrency safe ': r) a -> Sem r a?

[mdimjasevic]

@isovector , I guess this has slipped your attention because I merged this before you got a chance to reply. Here's just a reminder.

[mdimjasevic]

@isovector , I just pushed an empty commit to your fork/branch to trigger our CI that otherwise has a hard time figuring out it should run. I hope this is fine by you. Otherwise I can copy your branch into wireapp/wire-server and then clone this PR modulo the incoming branch.

[isovector]

@mdimjasevic thanks for being on top of it!