Establish snap source code size limit

[rekmarks]

Installing a snap should not cause the extension to blow up. Snaps of a certain size (>=100mb) are known to be able to cause the extension or entire browser to crash. We should empirically establish some upper bounds and set a reasonable limit.

Once the limit is established, we should:

• Warn about it at build-time
• Prevent snaps above the limit from being installed

[rekmarks]

Hey team! Please add your planning poker estimate with Zenhub @FrederikBolding @david0xd

[david0xd]

After some extensive stress testing and research I got some good results on this.

So, here is the table representing different scenarios of testing and outcome:	Bundle size	Installs?	Snap is running?	Can do long processing of data?	endowment:long-running enabled?
50 MB	Yes	Yes	Yes	No
75 MB	Yes	Yes	Yes	No
100 MB	Yes	Yes	No (timed-out and terminated)	No
100 MB	Yes	Yes	No (no response, snap crashed)	Yes
225 MB	Yes	Yes	No (no response, snap crashed)	Yes

Note about the way of running tests:

• Template Snap is used as the starter Snap template and environment for this testing.
• Each of test performed used base64 imported data and wrapped up into a bundle.
• For long data processing decoding of base64 string is used (Uint8Array.from(atob(base64String), (c) => c.charCodeAt(0));)
• Long data processing is started on RPC request and response from the snap have been awaited.

Further explanation of some stress testing scenarios:

• When large data was just accessed in the snap by accessing string length, no specific performance or stability issues were detected.
• All bundles of any size were installing perfectly.
• No crash on install is noticed. Web browser is stable, extension is stable and performs well, Snap itself is running.
• The only issue is when large data (100MB) is processed within a snap and when it takes long time to do so. In that case Snap becomes non-responsive and its state is identified as Crashed in the Snap Settings page.
• Files and some ideas are taken from these repos: https://github.com/piotr-roslaniec/snap-large-files https://github.com/piotr-roslaniec/large-files

Details about environment on which tests have been performed:

• Operating system: MAC OS 12.6
• Chip (CPU): Apple M1 Pro
• Memory (RAM): 16GB
• Storage: 512GB SSD
• Web browser: Google Chrome (Version 107.0.5304.110 (Official Build) (arm64))
• MetaMask Flask version 10.22.0 (local build from develop branch)

[david0xd]

After the analysis of the research result, we made a conclusion that the results and measurements are good enough and are not a major concern. It is proven that the extension and web browser are stable and performing as expected under the circumstances of a "very large" Snap bundles. The conclusion is as well that this is not particularly memory problem as it was firstly identified to be, but rather problem of a long processing of large amount of data (>=100MB).

The long processing of large amount of data issue is forwarded to this ticket: https://github.com/MetaMask/snaps-monorepo/issues/981

I'm closing this one as we agreed when discussed on a standup.