Prevent addition overflow

[vicsn]

Motivation

We should avoid panics, this PR adds checking if additions are allowed in snarkVM. I could not find problematic subtraction cases.

For this, we should agree on the attack surface. I can imagine the following attack vectors:

• an attacker lets different nodes misinterpret a serialized object, which can happen if our flags are serialized last. Fortunately I haven't seen this anywhere.
• an attacker's frontend lets an honest user serialize a giant object so their local node panics, I don't think this is a huge issue
• an attacker lets an honest node deserialize a giant object so it panics. This might kill the network so we should prevent this. Nodes already seem to have a maximum message size, but as defense in depth I use saturating_add in serialized_size. Using checked_add there is tricky as it will change the serialized_size trait function signature all over the codebase, including in macros and for types which we know have a fixed size.

Test Plan

The existing tests should cover it.

Related PRs

Succeeding: https://github.com/AleoHQ/snarkVM/pull/1584
Compared to that PR, here we only care about fixing addition overflow and we are rebased on testnet3

[howardwu]

I think we can remove all usage of checked_add in these cases. It is unlikely we would wrap around a usize assuming a 32-bit or 64-bit architecture, because our SRS is only up to 2^27.

[howardwu]

I am open to changing our usage of usize to a u64 to truly mitigate this issue as well.

[vicsn]

Pushed and squashed the changes.

I am open to changing our usage of usize to a u64 to truly mitigate this issue as well.

For that topic, I will review and rebase this PR later: https://github.com/AleoHQ/snarkVM/pull/1499