Adds toDevice capability to matrix transport

[andrevmatos]

Thank you for submitting this pull request :)

Fixes #2195
Fixes #2204

Short description
Adds a protocol improvement which allows clients to advertise a new toDevice capability, and when both peers communicating through Matrix have it enabled, allows them to exchange messages without requiring room creation, invite logic and messages storing on server side.
This implementation is backwards compatible, and clients fallback to old room-based message exchange if either isn't compatible or have set this new capability.
WebRTC events can also be exchanged through this type of messages since #2158 .
Includes fixes for other transport issues found while debugging issues above, which happened only on stressing scenarios like BF6.

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. Run BF1, BF6 & BF7 scenarios
2. Check they pass accordingly

[codecov]

Codecov Report

Merging #2174 into master will increase coverage by 0.03%.
The diff coverage is 96.62%.

@@            Coverage Diff             @@
##           master    #2174      +/-   ##
==========================================
+ Coverage   94.76%   94.79%   +0.03%     
==========================================
  Files         156      156              
  Lines        6132     6170      +38     
  Branches     1146     1158      +12     
==========================================
+ Hits         5811     5849      +38     
+ Misses        259      258       -1     
- Partials       62       63       +1     

Flag	Coverage Δ
#dapp	92.05% <ø> (ø)
#sdk	95.92% <96.62%> (+0.03%)	⬆️
#sdk_e2e	68.07% <48.31%> (+0.14%)	⬆️
#sdk_unit	85.28% <96.06%> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
raiden-ts/src/config.ts	100.00% <ø> (ø)
raiden-ts/src/messages/actions.ts	100.00% <ø> (ø)
raiden-ts/src/polyfills.ts	71.42% <ø> (ø)
raiden-ts/src/raiden.ts	89.15% <ø> (ø)
raiden-ts/src/transport/epics/init.ts	96.52% <86.66%> (+0.06%)	⬆️
raiden-ts/src/transport/epics/rooms.ts	95.62% <92.30%> (-1.03%)	⬇️
raiden-ts/src/utils/rx.ts	98.00% <93.75%> (+0.63%)	⬆️
raiden-ts/src/transport/epics/webrtc.ts	97.74% <98.07%> (-0.95%)	⬇️
raiden-ts/src/constants.ts	100.00% <100.00%> (ø)
raiden-ts/src/transport/epics/helpers.ts	100.00% <100.00%> (+1.53%)	⬆️
... and 4 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 79678d0...4eb8e6b. Read the comment docs.

[weilbith]

Thanks for adding this feature. I think it is a great addition. 🙃
Some epics have become way better to read. Good work to improve them! 💪

Disclaimer:
I stopped to read one of your commits. I was stating in its message sdk: better handle matrix rate-limit errors. Why was this necessary (not required to write) and what is the higher level idea of your solution. This PR is huge. I barely have a chance to evaluate it without having an idea what your plan was. Therefore it is simply to big. Also I guess that not all of the changes where actually related to what the messages states. This makes it even harder. This might be okay to include such changes into the same commit, but usually you add then a paragraph in the body of the message to inform about it.
I think if we can improve on these messages for more complicated or just bigger changes, this will make PRs much more efficient. Reviewer can focus much better on the logic rather than understanding code.

It is again one of those reviews where I think the changes are good and many commits are totally clear and fine. But I can't provide an 100% approval.

[palango]

I agree with Thore in that this is a huge chunk and hard to digest.

I have a question about testing of those features:
We now have a base layer for communication consisting of Matrix. This can either be "normal" rooms or toDevice messages depending on capabilities. On top there's webRTC, which is enabled based on a capability and negotiated based on one of the above method.

How is this big matrix of possible combinations tested? I'd expect (from the python codebase) to see a heavily parametrized test with two nodes on a matrix of the above features, testing that each combination works as expected.
Can you point me to those tests if they exist?