refactor: remove duplicate chain extensions across runtimes

[Daanvdplas]

I think we should create a separate folder for the extension in the runtime folder, outside devnet/testnet, which the runtimes than take as a dependency, similar to a pallet. We can then have a devnet and testnet feature in the extension crate so that we can deploy new integrations separately first on devnet and then testnet, but still being able to work in one folder instead of all the different runtime folders. The common folder doesn't make sense to me since there are non common things as mentioned above.

Astar has something similar but outside the runtime folder: https://github.com/AstarNetwork/Astar/tree/master/chain-extensions. I would like to maintain it in the runtime folder.

As for the tests, I think we should create a test folder in the chain extension crate where we divide the tests per use case; e.g. fungibles, non-fungiles.

[al3mart]

Agree on keeping pop exentions in the runtime

[evilrobot-01]

I guess the rationale for it being outside the runtime directory is simply a classification, where the subdirectories are implementations of runtimes. No big deal either way to me.

I think it probably makes sense, but a few things to consider:

• features are additive and making them mutually exclusive is possible, but somewhat tricky. The devex may not be great but seperate implementations is also not great. Also consider how it might work with mainnet. Do we end up in feature hell?
• some type bounds on the extension will probably need improving. For example,

  pop-node/runtime/devnet/src/extensions.rs

  Line 44 in 33505ba

  AccountId = AccountId,

  ensures that an associated type is the same as the AssetId type alias, only defined in that runtime, or possibly common). Unlikely that types will deviate across runtimes, but will moving them result in additional complexity through generics/type bounds, slowing development.

[Daanvdplas]

But will most differences between devnet, testnet and mainnet not be additive? I'm thinking in light of adding new features

I see your point though where constants can be chosen to be different which is not additive, I found this implementation used by frequency which we can take as an inspiration: prod_or_testnet_or_local

[Daanvdplas]

Nevertheless, this requires more careful consideration and refactoring the tests is urgent for now so I will only do that.

[chungquantin]

I am taking a look at the current testnet extension to migrate, but seems like it is quite out-dated right now (no versioning support so the env buffer is decoded in a different way, first two bytes in devnet is a version while first two bytes in testnet is a function ID), wonder how would we want to handle it?

1. Should we halt the separation until the pop-api is deployed on testnet with new chain extension and start separating.
2. Trying to make the separated extension backward compatible with the current testnet chain (but this would not be ideal because testnet is far behind)
3. The separation PR should apply the devnet chain extension architecture (with versioning) to the testnet as well but disable functionalities related to fungibles.

[evilrobot-01]

Perhaps it can simply start by moving the extension to common and having devnet use it from there? That should allow easier use by other runtimes when ready.

[chungquantin]

Close #163