Abstract away the executive

[gupnik]

This PR adds the ability to auto-generate the Executive inside construct_runtime. It also creates wrappers on Runtime that internally call the Executive's APIs.

In order to enable this, simply provide a Migrations tuple like so:

construct_runtime!(
    type Migrations = (...);
    pub struct Runtime {
         .....
    }
)

Extension:
We should be able to generate a number of Runtime APIs internally.

[kianenigma]

I generally like this direction. Such simplifications, especially when backwards compatible, can help reduce the hassle of setting up tests and simple runtimes a lot.

I would imagine a syntax like this, avoiding furthe "shady Rust":

// Valid, no migration, no need for executive.
construct_runtime_next {
  struct Runtime { ... }
}

// Valid, some custom migration.
construct_runtime_next {
  type Migration = ..
  struct Runtime { ... }
}

// Valid, custom executive
construct_runtime_next {
  type Executive = ..
  struct Runtime { ... }
}

I am also suggesting that we somewhat make this be a new macro, as I can't find an easy way to make it fully backwards compatible. But this can be solved in different ways.

Regardless of my suggestion above, I think the struct Runtime<<Migration> is a bit iffy, but there could be multiple different alternatives.

[gupnik]

@kianenigma I have updated the syntax as per your suggestion.

Now, we just need to provide a tuple type Migrations = (...) to enable this. In its absence, it defaults to the old behaviour, thus ensuring backwards compatibility.

Please let me know your thoughts.

[kianenigma]

This will play nicely with the new frame crate, it should re-export the frame-executive.

[kianenigma]

This is kinda cheating, if you want to be pedantic. There's now no good way to configure this. But I am not sure if this is all that useful.

[gupnik]

Yeah, I will add the support to provide a custom Executive as well, using the syntax you suggested above.

[bkchr]

Why don't we start working on a new construct_runtime! syntax, instead of trying to add more to the current macro. paritytech/polkadot-sdk#232 there was already quite some discussion and the ideas of this pr could be added there as well.

[KiChjang]

Does it work if you use (Dummy,)?

[gupnik]

Yes, it parses correctly and throws the correct error.

[liamaharon]

Why don't we start working on a new construct_runtime! syntax, instead of trying to add more to the current macro. paritytech/polkadot-sdk#232 there was already quite some discussion and the ideas of this pr could be added there as well.

I agree, the mod runtime syntax described here paritytech/polkadot-sdk#232 would be a huge step up imo. These small incremental improvements to construct_runtime! are cool, but are they worth working on if there're few blockers to replacing it entirely with something better?