Remove any unchecked arithmetic

[Voxelot]

In order to prevent overflows and unpredictable behaviors, all arithmetic (esp gas or free balances) should use checked_* operations rather than std ops like AddAssign. In cases when we know that it is not possible to fail or the context around is valid, then we can ignore or expect the operation.

The main idea is to make the code safe and keep API as simple as possible. If the input from the user may invalidate the state/behavior, then we need to return an Option or Error.

It is better to do this change crate by crate to avoid conflicts with other PRs:

• fuel-merkle Deny clippy::arithmetic_side_effects for fuel-merkle #729
• fuel-crypto: Deny clippy::arithmetic_side_effects #725
• fuel-tx: Deny clippy::arithmetic_side_effects #725
• fuel-types: Deny clippy::arithmetic_side_effects #725
• fuel-vm: Deny clippy::arithmetic_side_effects #725

[Dentosal]

Just to elaborate on this: there are checked_*, overflowing_*, saturating_* and multiple other variants. The appropriate operation should be used. A comment (e.g. spec link) on why a specific variant was selected with overflowing_* or saturating_* operations wouldn't hurt either.

For optimization, there are also unstable and unsafe unchecked_* operations, which assume overflow cannot occur.

[Voxelot]

Looks like clippy has a lint for unchecked math, cargo clippy -- -D clippy::integer_arithmetic which results in 135 errors currently.

Once we've addressed this issue, we can add clippy::integer_arithmetic to our set of disallowed lints.

[MitchTurner]

After spending a couple of days on this, it's not clear the best approach. In terms of capturing the error effectively, it makes sense to return Result from any function that has checked arithmetic. Theoretically there is internal logic that could never go awry during healthy behavior, and for those functions we could #[allow(clippy::arithmetic_side_effects)], but in reality its very hard to tell which those are. For the rest of the functions, making them fallible (returning Result) clutters up the code a lot.

It was when those Results started bleeding into infallible functions in other crates (from fuel-merkle into fuel-tx) I really started questioning the value of these changes.

It seems more valuable to have thorough fuzzing/prop testing than be able to catch the error telling us the chain is bricked.

With all that in mind, I'm going to put this story back and work on higher-priority issues.