userlib: add a critical-section impl for task code.

[cbiffle]

The embedded ecosystem is starting to catch up with the fact that not all of us are running a single address space in privileged mode, and crates like portable-atomics may now be in a state where we could rely on them.

Implementing things like atomic polyfills on platforms without atomics requires some way to control concurrency, and crates seem to be standardizing on the critical-section crate -- which unlike the old critical section in cortex-m, can be customized for our purposes.

So, this commit adds a backing implementation to userlib to allow the critical-section crate to be used in tasks. I'm slightly alarmed to note that our dependency graph already includes a very old version of critical-section, but I'm pretty sure that should be safe since we've never provided an impl for it. It is presumably not being linked in.

I need to do more work to evaluate the code generation of crates like portable-atomics, but this part, at least, I think we can probably land.

[github-actions]

license-eye has totally checked 508 files.

Valid	Invalid	Ignored	Fixed
507	1	0	0

Click to see the invalid file list

• sys/userlib/src/critical_section.rs

[hawkw]

looks good to me --- i'm excited for the subsequent PR to get rid of armv6m-atomic-hack!

[hawkw]

it occurs to me that a very nice side benefit of Hubris' use of separate compilation for tasks is that we can allow an individual task to opt in/out of global userlib behaviors using Cargo feature flags --- if we had instead implemented tasks as a bunch of crates that were all dependencies of a single top-level build, feature unification would mean that one task opting out of the default critical_section impl wouldn't work, as other tasks would still be enabling the feature flag. it might be worth discussing this in the benefits of the separate compilation model in docs/talks!

[cbiffle]

it might be worth discussing this in the benefits of the separate compilation model in docs/talks!

@hawkw fwiw, this is also why we tend to appear in discussions of changing Cargo's feature unification behavior -- this is great behavior for our purposes, but is really annoying for some other people!

Explaining the use case publicly would probably help, you're right.