[Polysemy] Introduce the row type variable in Brig

[mdimjasevic]

This is the first PR in a series of PRs that introduce Polysemy to Brig. It introduces the row type variable to several monads in the service.

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.

[pcapriotti]

This doesn't look right. The prism doesn't actually get used, so this will catch any exception, rather than the one identified by the prism.

I'm not sure why handler_ requires a typeable constraint (probably a limitation of Control.Monad.Catch), but that means this code should run in IO (or some simple monad stack over IO), and later be lifted to the AppIO/polysemy monad.

Or, for the time being, you can add a Typeable instance to AppIO.

[mdimjasevic]

Thanks for spotting this. I'll take a look at how to fix this.

We didn't want to introduce the Typeable constraint on AppIO as that would propagate the constraint further up the call stack, and this doesn't look like the right thing to do.

[fisx]

Except for the noise, adding Typeable constraints is trivial and easy, and the reason it needs to be added explicitly is rather technical. I wouldn't spend any effort trying to avoid it.

[mdimjasevic]

(Sorry, I keep on forgetting not to rebase once a PR is under review.)

I took Paolo's suggestion and turned the helper function to run in IO instead of running in a constrained monad m. See 1abfd3c for details.

@fisx , @pcapriotti , is that OK now?

[pcapriotti]

Looks good!