Remove Multisig example contract

[HCastano]

This PR removes the Multisig example contract in preparation of the (temporary) removal
of the ink_storage::collections crate.

This example is the only one we have which makes use of the ink_storage::{Vec, Stash}
data structures, which at the moment don't play nice with the non-caching data structures
which we want smart contract developers to use (see #1070 for a little bit of context).

This is a good example though, so once we re-work the collections we should bring it
back.

[xgreenx]

You don't need to remove the whole example. You easy can use ink_storage::lazy::Lazy<ink_prelude::vec::Vec<AccountId>> instead of StorageVec and later update it to use a new vector without caching. That example can be useful for people without a new vector=)

[athei]

But I think we don't want people to use that either? Doesn't that explode the file sizes?

[xgreenx]

ink_prelude::vec::Vec takes much less space than ink_storage::collections::Vec. The main idea of multisig example is to show how to do a cross-contract call, how to define your own structures, how to manage transactions. It is not production example of the multisig, but it shows well how to work with ink!.

[HCastano]

@xgreenx so the other problem here is the use of Stash, which uses a LazyIndexMap internally. I think it's possible to re-write the contract without using it, but I want to push that down the road a little since we're trying to push for a stable release soon

[xgreenx]

@xgreenx so the other problem here is the use of Stash, which uses a LazyIndexMap internally. I think it's possible to re-write the contract without using it, but I want to push that down the road a little since we're trying to push for a stable release soon

I see. Yes, I think it should use Mapping and use a hash of the transactions as TransactionId instead of the index in Stash=) But if you want to re-write it later, okay. When do you plan to do a stable release? Because it still contains several critical bugs for users=)

[HCastano]

When do you plan to do a stable release? Because it still contains several critical bugs for users=)

@xgreenx So the main things as far as ink! is concerned are

• Non-payable constructors, since this is a breaking change
  • This is mostly just waiting for UI support
• Removal of non-caching collections
  • It's easier to add back code than to remove it later
• Removal of the old off-chain environment
• Storage deposit support
  • There's a PR open for this, but is waiting on some off-chain env stuff

We think that any other issues can be addressed in minor releases later. Out of curiosity, what issues do you deem as critical? I suspect #982, but anything else?

[athei]

Ported the multisig example. However, the off chain tests are failing with an error I don't comprehend. Maybe someone can assist me with debugging: #1078

[xgreenx]

We think that any other issues can be addressed in minor releases later. Out of curiosity, what issues do you deem as critical? I suspect #982, but anything else?

Yes, #982 is critical because it doesn't allow to use of traits fully and no workaround exists.

#1000 has a workaround, but it is related to #809 and I think that resolving it can change the API, so why it is also is critical.

#900 requires additional follow-up change which affects selectors in trait.

Did you clean up all stuff related to that? #906

[HCastano]

Yes, #982 is critical because it doesn't allow to use of traits fully and no workaround exists.

On the surface this seems like something that we can add after the 3.0 release without breaking anything for users, but I don't have a lot of insight into this tbh.

#1000 has a workaround, but it is related to #809 and I think that resolving it can change the API, so why it is also is critical.

Again, on the surface this looks like the API could be backwards compatible, but don't quote me on this.

#900 requires additional follow-up change which affects selectors in trait.

I'm gonna defer to @cmichi here since he's been chatting with you in that issue

Did you clean up all stuff related to that? #906

So a bunch of stuff was removed in #1036, but I think there might still be some more to clean up.

Btw, we probably shouldn't be having this discussion here. @cmichi can you enable "Discussions" for the repo so we can move this conversation there?

[HCastano]

Closing in favour of #1078.