Allow registering parathreads in pallet_registrar genesis

[tmpolaczyk]

To actually add them we will need to modify the chain spec manually, probably using a javascript script

[github-actions]

Coverage Report

(master)

@@                           Coverage Diff                            @@
##           master   tomasz-genesis-registrar-parathreads      +/-   ##
========================================================================
- Coverage   66.71%                                 66.63%   -0.08%     
+ Files         260                                    261       +1     
- Lines       44818                                  44717     -101     
========================================================================
- Hits        29897                                  29794     -103     
+ Misses      14921                                  14923       +2     

Files Changed	Coverage
/pallets/invulnerables/src/lib.rs	85.59% (-0.90%)	🔽
/pallets/registrar/src/lib.rs	88.73% (-0.09%)	🔽

Coverage generated Wed Jul 31 09:11:44 UTC 2024

[girazoki]

Maybe we should find a way to pass them as parathreads. Maybe the cleanest is with a new command line argument dont you think? Or alternatively, something in the spec that indicates whether it is a parathread..

[girazoki]

I think the PR is good but I would love to see a way for us injecting parathreads without going through manually changing the spec. However the only way of doing is I think is by:

• A chain-spec container file from which we can read the parathread-params from some attribute
• A different command that asks for two arguments, the json file and the parathread params for parathreads.

I am not sure how feasible is the latter (or even, how user-friendly)

[tmpolaczyk]

I feel that parity wants to move all the genesis stuff out of the node binary and use the chain_spec_builder binary instead. I don't know how that binary works yet so not sure if that's a good idea.

But with that in mind, I was thinking of deprecating the --add-container-chain flag, and instead using a javascript script. Then we could have that script accept a genesis json patch file as input, and optionally the container chain paths like we do now. Because having to add a new flag to the node binary every time we add a new field in a genesis config feels wrong. We still will have to add some flags, but for most of them they will be defined in the patch json file instead. So in the parathread example, the parathread params should be part of the json patch and not the cli.

And also we could merge all the build-spec-*.sh scripts into a single one with subcommands or args to toggle dancebox/flashbox and num collators.

But I don't want to do any of this in this PR, as it would be a big change and probably break our zombienet tests.

[girazoki]

sounds fair enough yes. I think what you want to do is something similar to what zombienet does right? In that case I am fine with it yes. Take into account that #629 adds the command line flag for starlight too, so please wait until it is merged to apply changes over it