Introduce Parathreads (runtime)

[gavofyork]

TODO

• Upgrade to latest Substrate + Refactor key management substrate#3213 (using that branch and premerged with Update to latest Substrate #340 )
• Make build
• Fix tests
• Add new tests for parathread and altered parachain functionality.
• Introduce new modules and linkage to the runtime libs.rs
• Refactor TypeId so it doesn't pull in sr_io and the memory management stuff.
• Check that the accumulator logic (which uses the chain's state) isn't an issue for the tx queue otherwise we'll construct invalid blocks when there's more than the ThreadCount number of selection transactions waiting

[gavofyork]

@tomusdrw don't know how well this will work with the current txqueue model... it assumes that we retain these changes in the candidate block's state as we populate our candidate block with txs from the tx queue.

[tomusdrw]

I don't fully understand how it relates to the pool, but if you call validate not only during validate_transaction but also during apply_extrinsic the changes will indeed be retained.
However when we import extrinsics to the pool they will runt validate_transaction on a pristine state of latest block and the changes are obviously not persisted.

Is that what you had in mind or did I miss your point completely?

[gavofyork]

it should work ok like that, i think.

but generally, these transactions are a little more sophisticated than usual. there are several instances when they can become invalid:

1. the head-data-hash given in them is not (or no longer) the hash of the parathread's head-data. this can happen because:
   a. it was old when we received it (should never be imported into pool)
   b. it was an alternative fork (should never be imported into pool)
   c. the parathread has progressed since we received it (should be thrown out as soon as this happens).
2. two of them are for the same parathread with the same head-data-hash. in this case the one with the lower fee/priority should be discarded as the other will always supersede it.
3. some number (registry::ThreadCount) of parathread progressions have already occurred in this block. in this case, the transactions should remain in the pool as long as their head-data-hash has not become outdated.

as i understand it, the pool should import them as long as the HDH is current, it will correctly construct blocks with them properly prioritised (this just uses the fees priority) and it will avoid putting in more than it should into a block.

to make it proactively discard duplicates, we presumably need to ensure that their provides includes the same tag, which should fulfil the needs for (2).

but in order to get (1c) working, we'd need to essentially re-check the validity after each block is imported. does the queue do this already?

[ltfschoen]

Suggested change

	fn register_parathead(origin,
	fn register_parathread(origin,

[ltfschoen]

Could we use type aliases (as mentioned in previous comment https://github.com/paritytech/polkadot/pull/341/files#r308993502) to change Vec<u8>, Vec<u8> to something like CodeHash, InitialHeadData (if my assumption of what they represent is correct)?

[ltfschoen]

various nitpicks

[shawntabrizi]

Some fixes to help this branch compile can be found here:
#470

Although, I ran into some issues and will need to talk to a rusty person.

[gavofyork]

ensuring ordering of active_parachains matches expectations (the set_heads extrinsic expects them to be ordered), while on_finalized of registrar expects something else

Addressed in 78d6b53.

weight of deregistration is off - it is O(n)

It's part of a wider issue that existed before and i'm not sure if here is quite the right place to manage it.

storage leak of pending swap map (unless I missed something)

Fixed.

other nits and grumbles from myself and Shawn

Generally addressed.

[rphmeier]

Looks good after re-review.
Fine with deferring the queue management to beyond this PR.