revive: Limit the amount of static memory a contract can use

[athei]

This will make sure that when uploading new code that the declared static memory fits within a defined limit. We apply different limits to code and data. Reason is that code will consume much more memory per byte once decoded during lazy execution.

This PR:

1. Remove the MaxCodeLen from the Config to we maintain tight control over it.
2. Defines a single STATIC_MEMORY_BYTES knob that limits the maximum decoded size.
3. Enforces them only on upload but not on execution so we can raise them later.
4. Adapt the worst case calculation in integrity_check.
5. Bumps the max stack depth from 5 to 10 as this will still fit within our memory envelope.
6. The memory limit per contract is now a cool 1MB that can be spent on data or code.
7. Bump PolkaVM for good measure
8. The blob is limited to 256kb which is just a sanity check to not even try parsing very big inputs.

[xermicus]

LGTM

[koute]

FYI, you have the next_multiple_of method on primitives you can use instead of this helper.

[athei]

Ahh yes. This function panics on overflow, though. Hence, I forced the inputs to be u32 and do the rounding in u64. When we switch to 64bit we probably just error out when the section sizes don't fit into u32.

[koute]

1. For all of the u32 -> u64 casts you could use u64::from, which I think is nicer as it will give you an error if this cast ever becomes truncating (in PolkaVM I have a clippy lint set up for this).
2. Alternatively, instead of the saturating_* spam you could use core::num::Saturating wrapper plus a local trait to make it nicer, but this might be a complete overkill.

trait Cast {
    fn cast(self) -> Saturating<u64>;
}
impl Cast for u32 {
    fn cast(self) -> Saturating<u64> { return Saturating(u64::from(self)) }
}
impl Cast for usize {
    fn cast(self) -> Saturating<u64> { return Saturating(self as u64) }
}

let memory_size = blob.len().cast()
    + program.ro_data_size().cast()
    - program.ro_data.len().cast()
    + ...

[athei]

1. Yes to the first point. I replaced by into where possible. The code then breaks when we upgrade to 64bit and we need to re-evaluate.
2. Looking at the saturating_* spam gives me a piece of mind. Seeing raw arithmetic is kinda triggering :)

[koute]

Shouldn't the WasmBlob be renamed? (: (Not necessarily in this PR of course.)

[athei]

Yes there is a lot of renaming to do. I am pushing this of because this will be a nasty PR.

[pgherveou]

maybe just use VM_MIN_PAGE_SIZE from polkavm-common?

[koute]

That constant's not for public consumption. (: (In general everything is 'polkavm-common' is private)

Besides, what matters is the page size that's configured, not what the minimum supported is, so this way is how it is actually intended to be used.

[pgherveou]

Suggested change

	.saturating_div(4);
	.saturating_div(EXTRA_OVERHEAD_PER_CODE_BYTE);

[athei]

This is to account for memory allocator overhead (see the docs above). But it's a good point: All those numbers should have names.

[athei]

Replaced by constants