Split locked epic and make it handle channels in parallel

[andrevmatos]

Description

Relatively simple refactor. raiden-ts/src/transfers/epics/locked.ts transfer epic contains all the logic which atomically mutates a channel state on off-chain messages. More specifically, it emits actions as reaction to off-chain messages and user's requests, which reduce channel's and transfer's state in a serialised manner, allowing e.g. async (even interactive) signing of a LockedTransfer while ensuring no other action will mutate the nonce below it. These operations can only ever change a specific transfer and a specific channel's state, so we can/should allow it to be performed in parallel per channel, instead of serially on all channels. They happen for transfers and withdrawals.

The current state isn't that big of a bottleneck currently, since the normal usecase, with either subkey (dapp) or raw key (cli) allowing for very fast/synchronous signing, but it's still sane to do and may allow more transfers to be performed in parallel.

While at it, it should be easy to split this epic ffurther, since this already got too big at more than 1.2k LoC and is a codesmell in codeclimate.

Acceptance criteria

• Transfers and withdraws are serialised per channel, instead of globally, allowing multiple channels to be mutated in parallel
• locked.ts is split further

Tasks

• use a groupBy to split handling of these actions/messages per channel
• split epic module into submodules

Why do this?

Refactoring that improves the code quality and reduces the chance of channels that take a long time processing transfers and withdrawals which could delay other channels processing in parallel. It may also improve the performance of many transfers happening in parallel in many channels.