Include first runtime in kitchen

[JoshOrndorff]

Begins to address #29 by adding a runtime section, and a first runtime, to the kitchen.

@4meta5 I'm particularly interested in your thoughts on this.

What I've contributed in this PR is just a runtime. Not a complete node. This is a departure from the paradigm that the runtime lives inside the node-template. I didn't do this as a conscious choice at first it just ended up happening, but I kind of like it. So the question is whether it is a good idea to package just runtimes. I kind of like it because all the code for setting up the service and cli won't have to be duplicated for each runtime, or distract from what actually is part of the runtime and what's part of the client. But it does mean we'll need to export a default genesis config from each runtime. I think that's kind of a cool idea anyway. I can show an example once I get past the following errors.

Edit Removed some compile errors which I've now gotten past.

[JoshOrndorff]

So I now have this runtime successfully working in a node. I tried to create an example of providing a default genesis config, but I'm stuck there now. Hoping to get help from Technical Chat.

[JoshOrndorff]

There is now a super-node-genesis module to provide a default configuration. Ideally the config would be part of the same module, but for some reason I can't get the imports working. This is ready for review now.

I also have an interesting node template that doesn't include its own runtime, but rather pulls its runtime and genesis config from the recipes. The idea is that we could have a single node template (maybe included in the kitchen) that takes any runtime and wraps it with a basic node that uses babe and grandpa.

[4meta5]

Whoa, this is a really good idea. It would make it so much easier to go from module development to testing in the context of a basic node's runtime.

[JoshOrndorff]

I'm feeling good about this PR and would like to merge it soon.

I've also written a node that works with these runtimes. Notice there is no runtime folder in that repo, rather it brings in the runtime like this.

@4meta5 When would you like me to add that wrapper node to this repo?

• Before merging this PR
• In a separate PR
• Never

[4meta5]

@JoshOrndorff you can add it in this PR; I'm comfortable with merging thereafter. I'm also comfortable merging as is...

[shawntabrizi]

@JoshOrndorff @4meta5 You will run into an issue very quickly where there is a hard-coded limit of 30 modules in a runtime from Substrate core.

It may make sense to list every module in the construct runtime as "commented out" with instructions for the user to enable the "up to 30 they would want to test"