Change Capabilities format

[konradkonrad]

Description

This changes the capabilities according to the proposed changes in #6503 (comment) and/or #6503 (comment)

Fixes: #6503

copy and past from the issue:

Encoding/Serialization for use in matrix avatar_url

"mxc://raiden.network/cap?{capabilities_url_encoded}"

where {capabilities_url_encoded} is the url query parameter encoding of capabilities.

Rules for url encoding:

• bool values are encoded as "0" for False and "1" for True
• other values are encoded as strings
• lists of values are allowed

Deserialization / Decoding

The final interpretation of capability values is up to the receiving client, or rather the specified capability.

Implicit values / Handling of unknown values

• intentionally omitting (falsy or whatever) known default values is discouraged. Client implementations are asked to explicitly state all known capabilities.
• Client implementations have to deal with receiving new/unknown capabilities gracefully, i.e. they should expect the peer to act backwards compatible.
• Client implementations have to deal with not receiving known capabilities gracefully, i.e. assume the peer implementation is going to exert legacy behavior and therefore act backwards compatible.

Previously discussed versioning is postponed until there is a need for truncation of capabilities.

Example

avatar_url = "mxc://raiden.network/cap?Delivered=0&Mediate=1&Receive=1&webRTC=1&list_capability=one&list_capability=two"
capabilities_decoded = {
 'Delivered': False,
 'Mediate': True,
 'Receive': True,
 'webRTC': True,
 'list_capability': ['one', 'two']
}

Rationale for the decision

• proper url conform encoding is expected to avoid any sanitation issues when communicating with matrix servers
• json+base64 encoding was dropped because it is harder to inspect by humans
• url query parameters can be (de-)serialized by existing tooling/libraries
• the boolean convention (0,1) was necessary because there is no native format for boolean values in url parameters

[andrevmatos]

IMO, the '0' & '1' shouldn't be converted to bool, and instead handled as a number, where its truthness will do what's is supposed to on code which interprets these values as truthy or falsy. It should work though one way or another on the current cases (which expect only booleans), just leaving this here for completeness/correctness.

[ulope]

LGTM.

Some nitpicks below.