Compile release build of DevTools with default dart2js optimizations

[elliette]

Work towards #7192

It would be helpful for DevTools bug reports to have more intelligible stack traces. This PR changes DevTools to use unminified dart2js. See https://dart.dev/tools/dart-compile#js for information about the varous optimization levels.

[kenzieschmoll]

I think we need to update build_release.sh too. The automated builder that uploads DevTools builds to CIPD uses that script

[hannah-hyj]

I think this pr broke devtools_tool serve, it launches an empty website page now.

[elliette]

I think this pr broke devtools_tool serve, it launches an empty website page now.

Uh oh, thanks! Will take a look

[sigmundch]

I'm curious, is the use O1 is meant to be temporary while debugging the other issue or a permanent change?

Just in case this is not temporary, let me suggest a couple other strategies that could provide a better balance of performance and debugability.

1. Only disable minification. Since -O4 does a lot more than -O1, there is a risk that running at -O1 you'd see performance issues on DevTools itself come up. Internally, dart2js enables minification from -O2 and up. However, it also has a --no-minify flag that can turn it off while keeping all other optimizations enabled. Using --no-minify will keep DevTools performing at it's current performance level. Note: this is what flutter uses when you enable "profile" mode on web: fluter build web --profile.

2. Keep minification, but use our stacktrace deobfuscation tools. We created a few tools that are mainly used by internal apps today. These tools can desugar traces reported from a minified app by using the source-maps generated by dart2js. The deobfuscator can unmangle names, reverse error messages, and even split out inlined call frames (this requires dart2js source map extensions, which are enabled by default today).

The latter requires a bit more setup, but it's the recommended approach to ship minified apps and still be able to get meaningful stack traces from production runs.

[sigmundch]

Re option (2), I was trying to see if I could lookup the stack provided in #7305, but I noticed that devtools currently doesn't ship it's sourcemap file. Is that correct? Is it by chance built and saved somewhere that could be accessed retroactively?

If not, that would be the main thing we need to do to make it possible to use the deobfuscation tools. We could try to rebuild the exact same state, but it would require using the exact same version of flutter/dart as it was used at the time the release was made (in this example, for devtools 2.31.1), which is likely hard to do.