WIP: Feature ink metadata for substrate

[extraymond]

attempt to generate ink compatible metadata using ink_metadata::InkProject currently relies on unmerged branched of scale-info, ink_metadata.

[extraymond]

Looks great!

Please rebase against latest main and add Signed-off-by: real name <email@address> to each commit (or even better, squash into one commit)

Hope it's ok that I force merged --squashed all the changes into a new commit, I couldn't find a way to sign past commits without having to fix all the conflicts.

[extraymond]

@seanyoung Adjusted the address_length and variant sort as requested.

[xermicus]

So as discussed in chat we stick with the requirement to have at least one public message (substrate only).

• Contracts without means to interact with have very niche to no use case
• We do as ink! does
• Allows us the reuse the ink! crate.

I'll add a better check and error message in sema.

@extraymond is this OK for you as well? Or do you have a specific use case in mind for contracts without messages?

[extraymond]

So as discussed in chat we stick with the requirement to have at least one public message (substrate only).

* Contracts without means to interact with have very niche to no use case

* We do as `ink!` does

* Allows us the reuse the `ink!` crate.

I'll add a better check and error message in sema.

@extraymond is this OK for you as well? Or do you have a specific use case in mind for contracts without messages?

Yeah let's try this first.

[xermicus]

I implemented a sema check to catch contracts without public messages. How-ever, it would actually be fine for base contracts. ~~Declaring contracts without public messages as non-concrete some-how could solve the issue elegantly @seanyoung ? The goal is actually to just prevent metadata generation for those contracts.~~

EDIT: I thought a bit more about this. The check in sema can just check that a publicly visible function exist at all (over all the contracts, not in every single one of them). Additionally, codegen should be changed so that it does not generate code for contracts without public functions. Like that, having base contracts without public functions is perfectly valid and should work just fine.

[xermicus]

@LucasSte @seanyoung you can review this now. I won't merge until I can depend on some ink! v4 beta release, but that shouldn't matter.

[xermicus]

ink! release didn't happen this week. Pinned the dependencies so we can merge as soon as @LucasSte approves