Implementer's guide: downward messages and HRMP, take 2

[pepyakin]

Closes #1139
Subsumes #1399

This is a refined version of #1399 that uses channels for HRMP. Changes from the previous approach:

1. HRMP uses channels now. The channels behavior mimics that of XCMP. It's important to note that the messages are removed eagerly when a channel is closed or the para being offboarded.
2. Now we somewhat consider offboarding.
3. DMQ now is reserved exclusively for VMP. HRMP messages are not routed through DMQ.
4. To specify what messages were drained from the HRMP channels we introduce a hrmp_watermark into the candidate.

[rphmeier]

Is this comment about the value of the field when no messages are pending?

[pepyakin]

No, this comment refers to the initial state assigned to this field when a new fresh channel is created. One can answer a question if there are pending messages in the channel only having:

• the mqc head
• the receiver's watermark
• the preimage of the latest link (to extract the block number of the latest message)

FWIW, this is similar to what we have in XCMP

[pepyakin]

Some tabs sneaked in *.md again. Changed the configuration of my editor, so I hope this won't happen again.

[rphmeier]

UPD(pepyakin): see #1539 where this comment is expanded

We currently maintain an invariant that everything that is backed in the relay chain satisfies the checks on outgoing HRMP messages and watermark progression.

However, it is not clear to me how the validators are meant to check those things off-chain, because there is currently no runtime API that exposes these things. I think we want to expose this data from the runtime API, but we don't need to keep it available for secondary checkers because of the invariant I mentioned at the beginning.

I'm thinking of redefining LocalValidationData:

struct LocalValidationData {
    /// Validation data that needs to be persisted for secondary checkers.
    ///
    /// These validation data are generally derived from some relay-chain state to form inputs to 
    /// the validation function, and as such need to be persisted by the availability system
    ///  to avoid dependence on availability of the relay-chain state.
    persisted: PersistedLocalValidationData,
    /// These validation data are derived from some relay-chain state to check outputs of the validation
    /// function. Since the commitments of the validation function are checked by the relay-chain,
    /// secondary checkers can rely on the invariant that the relay-chain only includes para-blocks
    /// for which these checks have already been done. As such, there is no need for this information
    /// to be persisted by the availability system. Nevertheless, we expose it so the backing validators
    /// can validate the outputs of a candidate before voting to submit it to the relay-chain and so
    /// collators can collate candidates that satisfy the criteria implied by this field.
    non_persisted: NonPersistedLocalValidationData,
}

We could even merge GlobalValidationData into this, but that can be a later PR.

[rphmeier]

We can defer the ValidationData refactoring to another PR (#1539). This LGTM