feat: api fungibles pallet

[Daanvdplas]

Adds the api pallet implementing the psp22 interface. It resulted into an overall refactor of the pop api, mainly simplifying the implementation. Some small other relevant changes:

• Removal of old api code (sub0)
• Refactor of assets to fungibles feature in pop-api.
• Created a folder contracts in pop-api/integration-tests which is contains the contracts for the integration tests.
• Removed transfer_from tests since it was a copy from `transfer. This is still to be implemented.

Remaining todos:

• feat (pop api): transfer_from and decrease_allowance #104
• benchmark function for approve
• refactor: exclude encoding of reading state results in chain extension #101 - fixed in refactor: remove read state encoding #122

[evilrobot-01]

Left some suggestions on initial structuring to make it easier to reason and start out closer to how we may end up.

[evilrobot-01]

Shaping up, still a decent amount of comments sadly.

Also annoying to have to re-review changes which have already been merged to main, making this take much longer than expected.

[evilrobot-01]

Important question: what happens when v1 needed. Is the plan to create a whole new pallet, taking up an index in the runtime, or to just add new functions here?

If the latter, should these functions be prefixed with v0_ to indicate intentions? Whilst renaming wont affect encoding based on call index, it may break integrations using the name obtained via metadata.

[Daanvdplas]

This is hard to predict but this theoretically doesn't have to change, ever. As long as the standards are being used the api in the contract should never change. If parameter types change slightly, these should be handled in the pallet via a runtime upgrade but this won't require a different version because the type in the contract stays the same.

When a parameter gets added to pallet assets' transfer there is a list of things that will happen:

• For old contracts nothing will change, the pallet fungibles' transfer will add some logic via a runtime upgrade.

should these functions be prefixed with v0_ to indicate intentions? Whilst renaming wont affect encoding based on call index, it may break integrations using the name obtained via metadata.

Renaming: makes sure integrations outside of contracts won't break.
Not renaming: makes the code cleaner and there is a high chance we will never need it. If we need it in the end we can change the naming and integrations outside of contracts will break.

• New contracts can use a v1::fungibles::transfer where they provide the extra parameter. This function will have a different dispatchable index and will call the v1_transfer()

[evilrobot-01]

Significant improvement in quality, well done! I think you can probably tell by my comments that I feel this is effectively done now, apart from a few finishing touches.

I think this is a good demonstration of how future implementations should be done and the expected levels of quality, cleanliness and simplicity.

[peterwht]

Seconding Frank's comment, really good job on this!

[evilrobot-01]

Congrats! 🚀 I know you put a lot of work into this, so thank you for the time and dedication. I hope you are pleased with the result.

[Daanvdplas]

I think this is a good demonstration of how future implementations should be done and the expected levels of quality, cleanliness and simplicity.

I 100% agree, it is amazing how much it has improved the last couple of weeks.

Congrats! 🚀 I know you put a lot of work into this, so thank you for the time and dedication. I hope you are pleased with the result.

I'm very pleased with how it turned and how much I learned. Thanks for all the reviews and help, it got to this point by us together. Looking forward to implementing the rest of improvements and features and get the first pop api use case complete, ready for hacking!