Disallow unchecked arithmetic

[athei]

We are using Rust's overflow-checks instrumentation to make sure that no silent integer overflows happen in contracts.

However, using overflow checks in contracts seems to be problematic when also re-building std at the same time as we do. For example, this error cropped up from time to time: use-ink/ink#364

We were able to build around it but for RISC-V builds the workaround does not work. It seems like we are using those features in an unsupported way.

The solution I am proposing is to build without overflow and reject code using unchecked math during build with cargo contract. I think this is a good thing because it forces users to think about how to handle overflows: panic/saturating/wraparound.

We achieve this by doing the following:

• Fail gracefully if a contract specifies overflow-checks in their manifest
• Add an extra mandatory clippy pass which will run with our lint in deny mode.

[SkymanOne]

The concern I have around the issue I mentioned in the review in ink! repo. I have also thought about external crates that devs might use in the contract. How are we handling these cases then?

[athei]

Clippy does not apply to dependencies unless they are path dependencies.

[SkymanOne]

LGTM! Would be nice to add a test for a contract with unchecked arithmetic

[athei]

I moved the linting pass before the building pass. I also removed the numbered build steps. It is more or less useless to know how many build steps there are but it added a lot of complexity.

One downside is that build and lint have overlap in the warnings they show. Added a comment regarding that. AFAIK the only way around this is to manually list all warnings to disable (or parse from rustc output).

[SkymanOne]

I don't have a strong opinion on the build steps. But it was somewhat useful at what step the build failed

[ascjones]

LGTM

[ascjones]

Why remove the features from check?

[athei]

Because check now only runs clippy where we just pass --all-features. Of course we could discuss whether this is useful but I argue it is: We just wan't to lint all the code and not only a subset.