Fix teleport accounting and add some events (#3167)

* Stuff to help inspect the DMP activity

* Fix teleport accounting

* Fixes

* Fixes

* Fixes

* Fixes

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

@@ -73,7 +73,7 @@ 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. Reward all backing validators of each candidate, contained within the `backers` field.
-  1. call `Ump::enact_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 `Ump::receive_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 `Dmp::prune_dmq` with the para id of the candidate and the candidate's `processed_downward_messages`.
   1. call `Hrmp::prune_hrmp` with the para id of the candiate and the candidate's `hrmp_watermark`.
   1. call `Hrmp::queue_outbound_hrmp` with the para id of the candidate and the list of horizontal messages taken from the commitment,

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

@@ -56,14 +56,14 @@ Candidate Acceptance Function:
 
 Candidate Enactment:
 
-* `enact_upward_messages(P: ParaId, Vec<UpwardMessage>)`:
+* `receive_upward_messages(P: ParaId, Vec<UpwardMessage>)`:
     1. Process each upward message `M` in order:
         1. Append the message to `RelayDispatchQueues` for `P`
         1. Increment the size and the count in `RelayDispatchQueueSize` for `P`.
         1. Ensure that `P` is present in `NeedsDispatch`.
 
 The following routine is meant to execute pending entries in upward message queues. This function doesn't fail, even if
-dispatcing any of individual upward messages returns an error.
+dispatching any of individual upward messages returns an error.
 
 `process_pending_upward_messages()`:
     1. Initialize a cumulative weight counter `T` to 0
@@ -71,7 +71,7 @@ dispatcing any of individual upward messages returns an error.
         1. Dequeue the first upward message `D` from `RelayDispatchQueues` for `P`
         1. Decrement the size of the message from `RelayDispatchQueueSize` for `P`
         1. Delegate processing of the message to the runtime. The weight consumed is added to `T`.
-        1. If `T >= config.preferred_dispatchable_upward_messages_step_weight`, set `NextDispatchRoundStartWith` to `P` and finish processing.
+        1. If `T >= config.ump_service_total_weight`, set `NextDispatchRoundStartWith` to `P` and finish processing.
         1. If `RelayDispatchQueues` for `P` became empty, remove `P` from `NeedsDispatch`.
         1. If `NeedsDispatch` became empty then finish processing and set `NextDispatchRoundStartWith` to `None`.
         > NOTE that in practice we would need to approach the weight calculation more thoroughly, i.e. incorporate all operations

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

@@ -69,7 +69,7 @@ struct HostConfiguration {
 	/// stage.
 	///
 	/// NOTE that this is a soft limit and could be exceeded.
-	pub preferred_dispatchable_upward_messages_step_weight: Weight,
+	pub ump_service_total_weight: Weight,
 	/// The maximum size of an upward message that can be sent by a candidate.
 	///
 	/// This parameter affects the upper bound of size of `CandidateCommitments`.