build(profiles): make the dev profile suitable for embedded

[ROMemories]

Description

It is our opinion that the release profile should be reserved for production builds.
This makes the dev profile suitable for low-Flash targets we support, and will allow us to leverage debug_assert!s in debug builds.

Documentation of Cargo profiles can be found here: https://doc.rust-lang.org/cargo/reference/profiles.html

Issues/PRs references

Open Questions

Future work

• Change the laze configuration to use the dev profile by default, instead of the release profile, and allow to use release for production builds.

Change checklist

• I have cleaned up my commit history and squashed fixup commits.
• I have followed the Coding Conventions.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.

[kaspar030]

It is our opinion that the release profile should be reserved for production builds.

Actually I'd like to think more about what this actually means. Should I now not use the release profile for my testing etc.?
I'd rather postulate that the debug profile should not be used in production.

I actually usually run & test code using the release profile, because I think that almost all software development should put performance very high at the list of goals, and debug decidedly does not do that. So IMO debug is great for the automated tests, and when I need to actually debug something that doesn't work as expected - when stepping through code, extra performance doesn't matter anymore, but extra checks & asserts do.

Anyhow, this PR only adds the -Os to the debug profile, which is needed in any case.

[ROMemories]

Should I now not use the release profile for my testing etc.?

It is indeed my opinion that you should not.

I think that almost all software development should put performance very high at the list of goals, and debug decidedly does not do that.

I don't understand what you mean here; profiles are entirely defined by the combination of their default configuration and of our customizations. The only meaningful differences regarding performance between these two profiles now are debug-assertions and overflow-checks, whose impact I expect to be much less significant than the difference in optimization level.

So IMO debug is great for the automated tests

Tests (run by cargo test, which do not currently HIL tests) have their own dedicated profile, test (which by default is the same as dev).
Similarly there is a dedicated bench profile for benchmarks (which by default is the same as release), which we don't currently use.