New parachain runtime skeleton

[rphmeier]

This PR contains the implementation of the Initializer, Configuration, and Paras modules as described in the implementor's guide. It also includes mock code and unit tests for each of the modules.

I'm also submitting an amendment to the implementor's guide in 3c2dd39 and 8183638 because the past-code-pruning was slightly wrong.

Fixes #1147, #1146

[burdges]

LGTM

[drahnr]

The structure of the code looks good to me, a few matches replaced by if let Err(idx) = .. would make it easier to read since in almost all cases only the wrapped value of one enum variant is used.

The comments code ratio is 🎉 , a few longer names in signatures would not hurt in some places.

The DB writes are a bit cluttered with magic constants, but I don't think there is much we can do to improve that (adding dozends of const is not a solution in this case).

[drahnr]

Either the + One::one() is on the wrong side of the comparison to emulate a <= or it needs some additional explanation why the acceptance period is prolonged by one.

assume_intermediate, if provided, must be before at. If at is not within config.acceptance_period of the current block number, this will return None.

ap := config.acceptance_period
at \in [now - ap .. now] 
now - ap <= at
inversion / abort criteria:
! (now - ap  <= at )
now - ap > at
now > at + ap

[rphmeier]

TBH, I'm not sure why I added this constraint anymore. The goal was to prevent doing validation_code_at requests for stuff that has been pruned, but the PastCodeMeta::code_at function can safely return None when the data has been pruned, so it doesn't seem necessary.

Furthermore the constraint may actually lead to us rejecting validation code requests where we still have the code, in cases like (10, 15), and now = 10 + acceptance_period. This is clearly bad, as we care when 15 exits the acceptance period, not when 10 does.

So I'll remove this constraint and alter the tests to ensure that those cases are covered

[rphmeier]

ffe66b1

[montekki]

I have been comparing the code here with the implementors guide side-by-side and as far as I can tell they do not diverge. The thing that bothers me is that I don't think I understand that well what happens at which exact moments in time, probably I should do a re-read of the guide and the code.

[rphmeier]

The thing that bothers me is that I don't think I understand that well what happens at which exact moments in time, probably I should do a re-read of the guide and the code.

Yeah, the guide could also be better about that. The short version:

Seconded -> Backed -> Included
                          ^
                          |
                    Paras is here

Everything in the Inclusion module is about the transition from the Backed state to the Included state, and keeping code available while a candidate transitions from included to accepted. The Inclusion module invokes Paras and is responsible for transitioning candidates from seconded to backed to included, but that will be implemented in a follow-up PR.

PRs to the guide to clarify these things are also appreciated, as it can be improved by far.

[drahnr]

👍