[blazor-wasm] Improve handling OOM error, and surface it better

Example issue: https://github.com/dotnet/aspnetcore/issues/40528

If the initial heap size is too big (set via $(EmccTotalMemory)) then the user sees:

_framework/blazor.boot.json
blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1 Streaming compilation failed. Falling back to ArrayBuffer instantiation.  RangeError: WebAssembly.instantiate(): Out of memory: wasm memory
blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1 TypeError: Failed to execute 'arrayBuffer' on 'Response': body stream already read
window.Module.s.printErr @ blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1
(anonymous) @ blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1
await in (anonymous) (async)
window.Module.s.instantiateWasm @ blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1
createWasm @ dotnet.6.0.2-mauipre.1.22102.15.0nf0a6txvs.js?v=sha256-/5MtncfJpmo16luI9orAGCmbYEhUFE8G+iO2w9+y4x8=:1
(anonymous) @ dotnet.6.0.2-mauipre.1.22102.15.0nf0a6txvs.js?v=sha256-/5MtncfJpmo16luI9orAGCmbYEhUFE8G+iO2w9+y4x8=:1
blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1 Uncaught (in promise) TypeError: Failed to execute 'arrayBuffer' on 'Response': body stream already read
    at blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1:36928
    at async blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1:36900
    at async blazor.webassembly.js?v=pD9dkEr0gbzoZKvepQmzbYKQYka7z-K9H2I-m5Inpxc:1:36636

We should instead catch the OOM error, and maybe surface it as better error that the app can catch, and surface to the user. And log a useful error message on how to fix it, for the the app developer. And with https://github.com/dotnet/aspnetcore/issues/40547 , it won’t make an unnecessary second attempt.

@kg @lewing @pranavkm

[CoryKoehler]

I am cross posting this as it may be helpful from https://github.com/dotnet/aspnetcore/issues/40547

"Hello, I put in an issue similar and closed it since this one seems to be the one where everything is tracked regarding this. I don’t think this can be pushed to .Net7. I am having customers complain currently on this. Depending on device (both Android and IOS are affected)

This to me seems huge and would make my clients rethink any investment in Blazor. An existing production site that is blazor wasm hosted that is having this issue is boatsforsale.com and replicate this issue with enough attempts on smaller devices. The site will display just a loading spinner forever and in the console you’ll see

Is there any way this could be looked into for an earlier release than next nov? @chassq "

–Edit below I see this is triaged and Prio1. Does this mean it will go sooner than nov? If so any idea on it? I do need to communicate this asap to my clients.

[CoryKoehler]

there is still a soft limit where your device or browser may not be able to allocate the requested amount of memory, and that soft limit is likely lower than 2gb on constrained devices like mobile handsets. in some cases instead of failing to allocate the memory the browser tab will go away because the mobile approach to memory management is to randomly kill processes when memory is low.

Ah I wish it was killing it when the error I mentioned further up happens. That would be a bit better than a forever spinner. But I will try this since it can’t be any worse I suppose. @todd-urbo