Implement Wasm validation for known issues/markers

[cmichi]

Closes #163.

Output currently looks like this:

…
 [2/3] Post processing wasm file                                                                                                                               
ERROR: Validation of the Wasm failed.                                          
                                                                               
                                                                               
ERROR: An error was found while compiling the contract:                       
The ink! message with the selector `0xAD931DAA` contains an invalid trait call. 
                                                                               
Please check if the mutable parameter of the function to call is consistent                                                                                    
with the scope in which it is called.                                                                                                                          
                                                                               
                                                                                                                                                               
ERROR: An unexpected panic function import was found in the contract Wasm.                                                                                     
This typically goes back to a known bug in the Rust compiler:                                                                                                  
https://github.com/rust-lang/rust/issues/78744

As a workaround try to insert `overflow-checks = false` into your `Cargo.toml`. 
This will disable safe math operations, but unfortunately we are currently not  
aware of a better workaround until the bug in the compiler is fixed.

[ascjones]

It would be possible to make it forward compatible if we wanted by adding these to an extra section in the generated metadata, though this would of course rely on the metadata being generated first.

[Robbepop]

It would be possible to make it forward compatible if we wanted by adding these to an extra section in the generated metadata, though this would of course rely on the metadata being generated first.

This protocol should not exist in the contract metadata since it has absolutely no value beyond cargo-contract. If it escapes cargo-contract's build it is already bad. Since it is a protocol I guess there is no proper way around providing an implementation on both sides: ink! serves and cargo-contract is a client. Please proof me wrong if I am.

[ascjones]

That makes sense.

There is still a way at least to provide some forward compatibility by detecting the common prefix __ink_enforce_error and enumerating the subsequent arguments even if we wouldn't be able to provide a nice error message.

[Robbepop]

LGTM

nice! 🚀

[ascjones]

This should probably still return a friendly string explaining that the EnforcedError could not be decoded, and the probable cause (a mismatch between the ink! version and the local definition).

[ascjones]

This could occur when e.g. ink! adds a new variant, and someone is running an outdated version of cargo-contract.

[ascjones]

LGTM