Improve memory metering for WASM VMs

[mootz12]

Problem

As Stellar's DeFi ecosystem grows, protocols built on top of other protocols are performing lots of cross-contract calls. The way memory is metered for WASM VMs puts an artificial ceiling on how many cross-contract calls fit within the per-transaction 40 MB mem_bytes limit.

By default, contracts compiled with stellar-cli declare a WASM linear memory with a ~1 MiB initial size. Each VM instantiation accrues that amount (+ more) to the mem_bytes meter and does not credit any back when the VM is torn down. For contracts with lots of sequential cross-contract calls, this causes them to hit mem_bytes limits without using much memory.

This has impacted builders a few times recently:

• Discussion to bypass cross-contract call mechanics to read data -> https://github.com/orgs/stellar/discussions/1958
• Discord question about hitting this building an interest rate derivatives protocol -> https://discord.com/channels/897514728459468821/1519974752771375164

Proposal

We add the ability to credit memory allocated for a WASM VM after it's frame is popped back to mem_bytes.

Alternatives

• The stellar-cli can likely safely reduce the WASM stack size down from 1 MiB for contract builds. However, this doesn't help contracts that are already live, like Blend. This should be explored regardless of the outcome of this discussion.

[mihaieremia]

Just to add more context, the best return on investment of such change will actually be towards the oracle providers, then the core lending/defi protocols.

If oracles will re build and re deploy the existing contracts with the new linear memory reduced, many protocols (mine included) will be more efficent in reading a bunch of prices for complex positions and in the future ETF style contracts calculating NAV, ETF price.