Followup HRMP issues after PR #1246

[serban300]

• [ ] Version HRMP channels
  • Without versioning, the two issues below are much harder to solve.
• [ ] Double encode XCMs in HRMP channels
  • for ensuring that one invalid message will not break the decoding stream and for efficiency as discussed here and here
• [ ] Backpressure mechanism improvements (suspend/drop/resume)
  • The sender will be granted protocol-credits by the receiver to send n messages. This gets replenished at the leisure of the receiver; ensuring that it will never have to drop messages.

[bkontur]

* [ ]  Backpressure mechanism improvements (suspend/drop/resume)

  * The sender will be granted protocol-credits by the receiver to send `n` messages. This gets replenished at the leisure of the receiver; ensuring that it will never have to drop messages.

@ggwpez @serban300 guys, do you have more information about these "protocol credits"?

[ggwpez]

This would be mostly a re-write of the HRMP protocol that instead of sending messages optimistically, always first checks how many "sending" credits (something like weight) it has left.
So for example:

• Para A sends a message to Para B to grant it 100 Credits
• Para B can now send up to 100 messages (trivial assumption that 1 msg = 1 credit)
• This ensures that Para A can regulate how many messages it receives per sibling and also globally
• Once Para A processed some messages, it can grant more to Para B or any other.

Some more advanced flow control logic could be added later, similar to torrenting, where channels that have many messages are prioritized. Otherwise a lot of these Credits would just idle and wait for a surge that never comes.

Does the general idea make sense? It is more pessimistic as to what we have now, at the expense of ensuring that the receiver is not overloaded.
It can be done backwards compatible with a version-upgrade protocol that elevates V1 channels to V2. But it is a rather big thing to do.