Reduce debug level for a faster incremental build

[smklein]

Depends on #4025

Improves incremental rebuilds of Nexus by about ~50% for debug builds on Linux, through a judicious reduction of debug symbols. This also reduces the size of binaries linking against Nexus significantly.

The benefits here seem like they'd be useful across the stack, so I've made this a toggle for the top-level workspace. I'm open to discussion about whether this should be applied more specifically to Nexus.

Part of #4009

[smklein]

For:

$ touch nexus/src/lib.rs && cargo build --timings -p omicron-nexus --tests

Before:

After:

[jclulow]

What's the purple part of the bars?

[smklein]

What's the purple part of the bars?

Codegen, I believe

[smklein]

What's the purple part of the bars?

Codegen, I believe

https://doc.rust-lang.org/cargo/reference/timings.html#:~:text=The%20%E2%80%9Ccodegen%E2%80%9D%20times%20are%20highlighted%20in%20a%20lavender%20color.%20In%20some%20cases%2C%20build%20pipelining%20allows%20units%20to%20start%20when%20their%20dependencies%20are%20performing%20code%20generation.%20This%20information%20is%20not%20always%20displayed%20(for%20example%2C%20binary%20units%20do%20not%20show%20when%20code%20generation%20starts).

The “codegen” times are highlighted in a lavender color. In some cases, build pipelining allows units to start when their dependencies are performing code generation. This information is not always displayed (for example, binary units do not show when code generation starts).

[david-crespo]

I don't know if this is a 1.72 thing or what but what the heck does this mean:

~/oxide/omicron $ cargo nextest run -p omicron-nexus
warning: ignoring unknown configuration keys in config file /Users/david/oxide/omicron/.config/nextest.toml: nextest-version
    Finished test [unoptimized + debuginfo] target(s) in 0.49s
    Starting 0 tests across 0 binaries
------------
     Summary [   0.000s] 0 tests run: 0 passed, 0 skipped

Attempting cargo nextest list, will update.

Update:

~/oxide/omicron $ cargo nextest list -v
    Finished test [unoptimized + debuginfo] target(s) in 0.66s

Uh.... I thought this might be #4024 but that's not even in this branch.

[david-crespo]

Ok, just for completeness here are all the things I tried because I was curious about the contours of the issue. Bad means no tests are found by nextest, good means tests are found.

• Nextest 0.9.53 + this branch: bad
• Nextest 0.9.53 + main: good
• Nextest 0.9.53 + main bumped to 1.71.1: good
• Nextest 0.9.53 + main bumped to 1.72.0: good
• Nextest 0.9.53 + this branch (again to make sure it's consistent): bad
• Nextest 0.9.57 + this branch: good

.config/nextest.toml says 0.9.55 is required, so I guess it was just that. But I still don't know what it is about this branch that causes the Nextest version to become relevant.