Notify when receiving transfers gets disabled

[andrevmatos]

Fixes #1473

TODO: tests, changelog

Short description
A dialog is shown on any screen on dApp when/if SDK has Receiving transfers disabled. This can happen on startup or during runtime, for mainly a couple of reasons:

• rateToSvt config mapping is empty (it is by default, so receiving is disabled until it gets populated)
• monitoringReward config isn't set (it is by default, as 5SVT)
• udcBalance is not enough to pay monitoring reward (which can happen at startup or at runtime by a withdraw from service or user I want to withdraw tokens from the UDC contract #1421).
• explictly disabled in user config with Raiden.updateConfig({ caps: { noReceive: true } }), which has priority

Definition of Done

• Steps to manually test the change have been documented
• Acceptance criteria are met
• Change has been manually tested by the reviewer (dApp)

Steps to manually test the change (dApp)

1. On dApp, acquire raiden SDK instance and enable receiving with:

raiden.updateConfig({
  rateToSvt: { '<token_addr>': '100000000000000000000' },
  caps: { noReceive: false },
 })

2. Reload, check no dialog is shown
3. Disable receiving explicity while connected:

raiden.updateConfig({ caps: { noReceive: true } })

4. See dialog shown which says receiving is disabled
5. One can also trigger dialog shown, even if caps['noReceive'] is unset (auto), if UDC balance is emptied, if one sets monitoringReward config to something higher than UDC desposit or rateToSvt is emptied

[nephix]

Should we provide a callback'ish way as well? I guess we haven't decided yet in #357

It's not multi step but same thing IMO

[andrevmatos]

Yes, I was thinking about it, I really want to standardize these interfaces, but didn't want to make this PR more complex, so just used the same pattern we already have for state$, channels$, transfers$ and so.. I'd say we should keep it like that for now, but I'm thinking on something like making Raiden an EventEmitter derived class and emitting these as events in a more interoperable way.

[nephix]

Looks plausible to me overall

[codecov]

Codecov Report

Merging #1548 into master will decrease coverage by 0.00%.
The diff coverage is 98.52%.

@@            Coverage Diff             @@
##           master    #1548      +/-   ##
==========================================
- Coverage   96.11%   96.10%   -0.01%     
==========================================
  Files         141      142       +1     
  Lines        5117     5138      +21     
  Branches     1004      954      -50     
==========================================
+ Hits         4918     4938      +20     
  Misses        155      155              
- Partials       44       45       +1     

Flag	Coverage Δ
#dapp	92.37% <100.00%> (+0.07%)	⬆️
#sdk	97.63% <98.03%> (-0.03%)	⬇️

Impacted Files	Coverage Δ
raiden-ts/src/types.ts	100.00% <ø> (ø)
raiden-ts/src/epics.ts	96.15% <95.00%> (-1.29%)	⬇️
raiden-dapp/src/App.vue	100.00% <100.00%> (ø)
...src/components/dialogs/ReceivingDisabledDialog.vue	100.00% <100.00%> (ø)
raiden-dapp/src/services/raiden-service.ts	88.96% <100.00%> (+0.14%)	⬆️
raiden-dapp/src/store/index.ts	100.00% <100.00%> (ø)
raiden-ts/src/raiden.ts	94.61% <100.00%> (+0.01%)	⬆️
raiden-ts/src/services/epics.ts	99.08% <100.00%> (ø)
raiden-ts/src/transfers/epics/init.ts	100.00% <100.00%> (ø)
raiden-ts/src/transfers/epics/locked.ts	98.20% <100.00%> (ø)
... and 7 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4058afe...56dff7d. Read the comment docs.

[taleldayekh]

Works like a charm, good job and thank you!