static_tests: Add test for Rust code formatting rules

[chrysn]

Contribution description

It is common for projects with Rust code to just enforce the code style suggested by Rust.

This adds a check to the static tests, and a second commits changes all the Rust sources to actually follow the code style (that is automated, cargo fmt does it).

Testing procedure

This PR should fail with a sensible message on the first run, and be green when I push the second commit fixing all the formatting errors (through the provided command).

Issues/PRs references

Thanks @Teufelchen1 for spotting the formatting errors.

This is a do-over of #20886 which GitHub killed.

[chrysn]

This is now based on #20888 to pass the other half of the static tests.

Static tests did fail as planned in job https://github.com/RIOT-OS/RIOT/actions/runs/11150914441/job/30993154634?pr=20887#step:6:87 when the old files were not reformatted.

The latest version now contains a commit whose content was generated by following the failing static check's suggestion, and should thus be ready for final review.

[riot-ci]

Murdock results

✔️ PASSED

d0299de static_tests/rust: Address shellcheck lints

Success	Failures	Total	Runtime
10197	0	10197	16m:35s

Artifacts

• Documentation preview

[maribu]

The CI has some comments.

The shellcheck output IMO is always good to react on, even if this is just adding a comment explaining why a certain anti-pattern is fine in a given context and locally disabling the corresponding shellcheck test with that comment.

[chrysn]

Good catch, how did you even find those outputs when they don't light up?

I had already commented on how the find is OK, but given that we have those checks, it's easier to just follow them than to put the appropriate overrides in place. (I think we're overlinting here -- chances are none of our systems are tested with non-GNU-compatible coreutils, and it's kind of inconsistent to accommodate old finds that don't do default path but not old shells that don't do $(), but meh, for here, I'm just fixing it, even if that means requiring bash to do it without a tempfile).

[maribu]

If you go for #!/bin/bash if you don't want to go for POSIX shell. Or we could tell the CI to assume at least the feature set of dash, which I believe is pretty much the botton end of features available as /bin/sh on typical dev machines.

For a script only run in the CI you can indeed just assume it is run on Ubuntu. I guess /bin/dash is want they use.

[chrysn]

I did go for bash and it's still yammering about some https://www.shellcheck.net/wiki/SC2031, fixing which once more pushing readability down. Next check I'll just write in Python :-)

[maribu]

No squashing?

[chrysn]

Squashed the two lint-addressing ones, but I do consider the others sensible and important steps. In particular, having the linter fixes independent from the original (working and thus well bisectable) code means that should I have gotten things wrong there (and I'd place the error probability around 50-50 between original code and the lint fixes), whoever fixes it (eg. future me after I've forgotten about this PR) has a chance of seeing both the original intention and where things went wrong.