split template into 2 opinionated runtimes: AccountId20 + AccountId32

[bernardoaraujor]

close #1056

[sorpaas]

My problem with this approach is that we now have a lot of duplicate code. You may think we can work with them alright, but it actually is a major source of pain whenever the runtime needs changes (which is frequent).

Would you mind to implement everything as feature gate instead? We continue to have a single runtime but just optionally built with either account types. I saw you already did it like that for some of the types and client construction code.

Also the feature gate accountid32/accountid20 is redundant. You just need to have one feature accountid20. If it's not enabled then we use accountid32.

[bernardoaraujor]

My problem with this approach is that we now have a lot of duplicate code. You may think we can work with them alright, but it actually is a major source of pain whenever the runtime needs changes (which is frequent).

Would you mind to implement everything as feature gate instead? We continue to have a single runtime but just optionally built with either account types. I saw you already did it like that for some of the types and client construction code.

Also the feature gate accountid32/accountid20 is redundant. You just need to have one feature accountid20. If it's not enabled then we use accountid32.

closing this PR in favor of #1186