Implementer's guide: downward messages and HRMP, take 2 (#1503)

* First stab at downward messages.

That also includes a notion of horizontal messages.

* Add some structure to the router.

* Update `ValidationOutputs`

* Add `processed_downward_messages` to `ValidationOutputs`.

Forgot to check that in.

* s/AccountId/ParaId

* DownwardMessage::ParachainSpecfic

* s/ensure_horizontal_messages_fits/ensure_horizontal_messages_fit

* Clarify that Router called for each candidate

* Update the preamble for Router.

* Rewrite the relay-chain extrinsic routines

* Update gloassary

* Add DMP to the glossary

* If the queue is empty, `processed_downward_messages` can be 0

* WIP

* Add condemned list

* Pivot to message-storing channel based HRMP

* Finished draft

* Tidy up

* Remove a duplicate glossary entry

* Fix typo

* Fix wording to emphasize that the channel is unidirectional

* Proper decrement `HrmpOpenChannelRequestCount`

* Add a comment for `HrmpOpenChannelRequestCount`.

* Remove old configuration values.

* Be more specific about the para{chain,thread} hrmp chan limits.

* Fix indentation so the lists are rendendered properly

* "to answer **the**" question instead of "a"

* Add a missing call to `check_processed_downward_messages`

* Clean more stuff during offboarding

* Fix typo

* Fix typo for the config

* Add a call to `prune_dmq`

* Add explicit invariants for ingress/egress indexes

* Add comments for the sender/reciever deposit config fields

* Document various fields and structs in Router module

* More docs

* Missing docs in Candidate.md

* Tabs to spaces in router.md

* Apply Rob's suggestion

* Add the hrmp_ prefix to the router messages

* Those are entry points

* Use SessionIndex type for the `age` field

* Use a struct to represent `HrmpChannelId`

* Put only MQCs into the LocalValidationData

* Close request can be initiated by the runtime directly

* Close request can be initiated by the runtime directly

* tabs/spaces

* Maintain the list of the outgoing paras in Router

* Update roadmap/implementers-guide/src/runtime/inclusion.md

Co-authored-by: Robert Habermeier <rphmeier@gmail.com>

* fix typo

* Remove an unnecessary pair of code quotes

Co-authored-by: Robert Habermeier <rphmeier@gmail.com>

polkadot/roadmap/implementers-guide/src/runtime/inclusion.md

@@ -69,6 +69,10 @@ All failed checks should lead to an unrecoverable error making the block invalid
   1. Check the collator's signature on the candidate data.
   1. check the backing of the candidate using the signatures and the bitfields, comparing against the validators assigned to the groups, fetched with the `group_validators` lookup.
   1. check that the upward messages, when combined with the existing queue size, are not exceeding `config.max_upward_queue_count` and `config.watermark_upward_queue_size` parameters.
+  1. call `Router::check_processed_downward_messages(para, commitments.processed_downward_messages)` to check that the DMQ is properly drained.
+  1. call `Router::check_hrmp_watermark(para, commitments.hrmp_watermark)` for each candidate to check rules of processing the HRMP watermark.
+  1. check that in the commitments of each candidate the horizontal messages are sorted by ascending recipient ParaId and there is no two horizontal messages have the same recipient.
+  1. using `Router::verify_outbound_hrmp(sender, commitments.horizontal_messages)` ensure that the each candidate send a valid set of horizontal messages
   1. create an entry in the `PendingAvailability` map for each backed candidate with a blank `availability_votes` bitfield.
   1. create a corresponding entry in the `PendingAvailabilityCommitments` with the commitments.
   1. Return a `Vec<CoreIndex>` of all scheduled cores of the list of passed assignments that a candidate was successfully backed for, sorted ascending by CoreIndex.
@@ -76,6 +80,9 @@ All failed checks should lead to an unrecoverable error making the block invalid
   1. If the receipt contains a code upgrade, Call `Paras::schedule_code_upgrade(para_id, code, relay_parent_number + config.validationl_upgrade_delay)`.
     > TODO: Note that this is safe as long as we never enact candidates where the relay parent is across a session boundary. In that case, which we should be careful to avoid with contextual execution, the configuration might have changed and the para may de-sync from the host's understanding of it.
   1. call `Router::queue_upward_messages` for each backed candidate, using the [`UpwardMessage`s](../types/messages.md#upward-message) from the [`CandidateCommitments`](../types/candidate.md#candidate-commitments).
+  1. call `Router::queue_outbound_hrmp` with the para id of the candidate and the list of horizontal messages taken from the commitment,
+  1. call `Router::prune_hrmp` with the para id of the candiate and the candidate's `hrmp_watermark`.
+  1. call `Router::prune_dmq` with the para id of the candidate and the candidate's `processed_downward_messages`.
   1. Call `Paras::note_new_head` using the `HeadData` from the receipt and `relay_parent_number`.
 * `collect_pending`: