Implement confirmation blocks

[andrevmatos]

Description

Currently, our blockchain interface through ethers treats any event as final, which could not be true if a reorg occurs. Raiden also don't see an event as confirmed before a given number of blocks (currently, default of 5).

Fortunately, our Rx/redux architecture provides a strong ground to support it in a selective manner, as some events may require confirmation and some don't.

This can use #591 between pending and confirmation events actions. Could also make use of #357 to update users about confirmation progress.

TODO: expand implementation description

Acceptance criteria

• Blockchain actions are emitted twice: on mining and upon confirmation, iff it was not removed due to a reorg
• On confirmation checks, need to take into account that the block in which the tx was registered could have changed since first mining, if a reorg took place
• Pending actions are serialized to state and cleaned upon confirmation; on restarts, pending actions can still be confirmed
• Try to take confirmation into account only when needed, as it slows SDK, e.g:
  • deposit actions should wait for confirmation, as partners aren't going to accept transfers anyway before it, but approves don't, as deposit will only be mined/confirmed if deposit is registed.
  • In the future (when we can receive/mediate), Secrets could be registered/detected as soon as they're seen on-chain, so we "know" the secret when/if they're revealed, even if the block is reorg'ed, but should wait/ensure confirmation if need to take actions depending on it being registered on-chain
• number of confirmation blocks is configurable

Tasks

• [ ]

[christianbrb]

@andrevmatos to describe the design / architecture / tasks