Refactor raiden messages as dataclasses

[andrevmatos]

(Discussion deadline: 2019-01-25)

Abstract

Currently, raiden transport messages gathered a lot of unneeded complexity. They were initially developed for python2, targeting binary serialization (udp transport), and then adapted to be JSON-serialized for Matrix, and with current tools, implentation could be way smaller, easier to understand, expand and version.

Motivation

The binary serialization is still depended upon as certain parts, as additional_hash is the hash of the binary representation of the whole message, and the _data_to_sign, the binary packing of the relevant members for the smartcontracts.
Nonetheless, these classes contain very little logic, and mostly carry the message data, making it very suitable for dataclasses, with some introspection making way for binary serialization as well.

Specification

My suggestion is to use attrs, which is already pulled as sub-dependency, possibly with help of cattrs for [de]serialization. These tools play very well with type annotations, making for a good declarative syntax of the structure and data included in the messages.
I prefer attrs over python 3.7's dataclasses mainly because of improved support for converters and validators. If we use sized data types (#3051), introspection can greatly simplify [de]serialization algorithms, as well as allowing strong data integrity/consistency guarantees.

Suggested approach:

• Finish type system improvements on fixed size datatypes and messages #3051 and provide most common [sub]types which will be members of the messages (no need yet to implement it in the whole raiden codebase yet)
• Base attrs class containing methods for binary serialization of members on specific orders and using size hints provided by sized types as above
• Declarative message classes with attrs and above base, ensuring binary serialization fields on same order as now (suggestion ref: pep 520)
• Make it sit in a versioned module (first step towards Make Raiden messages forward and backward compatible -- message versioning #2161)

Some inspiration can be drawn from this old branch/experiment: https://github.com/andrevmatos/raiden/blob/refactor_messages/raiden/messages2.py

Backwards Compatibility

Proposal above should be fully compatible with current implementations (same binary serialization, hashing of additional_data, data to be signed, and JSON encoding as well), while simplifying codebase on these matters and helping understand, expand and enforce types and limits.

[andrevmatos]

This approach could be extended in the future for other dataclasses in core as well, specifically in states, state changes and internal events (TBD)

[ulope]

In Monday's transport teem meeting we decided on a deadline for discussion on this issue no later than 2019-01-25.

[hackaugusto]

Please, don't go about refactoring the message without thinking about the rest of the code base. We should avoid using different approaches for the messages/state machines/data transfer object/etc.

[ulope]

(This has been talked about before, but just to document it in writing as well)
Related: #3302
When we're taking this on it would be a good opportunity to use better datastructures.

[andrevmatos]

As @hackaugusto said, we shouldn't do it independently of the rest of dataclasses on Raiden, but as transport's messages has some additional requirements to them (mainly, ability to binary-and-ordered-fields [de]serialize), and also have way more limited scope (they're accessed, serialized and deserialized in very specific places inside transport and messages handlers), I'd like to push for scoping this issue only for transport's messages and using it as a playground for this dataclass implementation, to be expanded to the rest of the dataclasses after it.
Implementation wise, I also liked pyrsistent, and would like to push doing this limited experimentation with it, which if mid-way shown as not enough, would not lose too much work and allow for simpler refactoring into any other solution may arise in the meantime.

[karlb]

To throw in one more option: dataclasses could be used with https://pypi.org/project/marshmallow-dataclass/ for (de)serialization