miri: integrate Bazel Miri tests in communication

[dcalavrezo-qorix]

• update rules_rust to 0.68.2-score
• update score_toolchains_rust to 0.9.1
• register the Ferrocene Miri toolchain for host builds
• add Miri wrappers for the communication Rust tests
• fix com-api-concept-test by adding the missing com_api dependency
• add a top-level miri_tests suite with the targets that pass under Miri today
• run the Miri suite in build_and_test_host after the Bazel test step
• there are tests rely on native FFI size/helper functions, which Miri rejects as unsupported foreign calls - those won't be included

[castler]

First, thanks for the efforts - but I think we need to be here very, very careful.

I understand to a minor extend, that we have a fork of rules_rust within S-CORE for QNX related patches. Anyhow, these patches should be integrated back into offical rules_rust. We really do not want to have a fork of rules_rust - and then even under the same name!
So features like this, should be really merged into the offical rules_rust and not into a mirror for patches!
We do not want to split the contributing community around rules_rust.

Second, while I highly appreciate the effort put into enabling miri - and I also think it is a must - I doubt the technical solution. From history, we have integrated pylint the very same way as it was done in this PR and we have seen quite quickly that it is impractical.
At the end we want to execute miri for all Rust related code and tests within the project.
Enforcing copy and paste around by re-adding this new rule everywhere will be hard to maintain.

IMHO we need to go the similar way, as we go with C++ Sanitizers. This must be an build option, and then all tests are executed under this toolchain. Best would be, if we would even use the same build option as the one from C++... --config=ubsan

I have limited knowledge about ´miri´ and how it operates, so I am not sure if we would need another rule, or this can be injected at compile time. But if we would really need another rule, I would propose to look into aspects to avoid the manual creation of these rules.

[dcalavrezo-qorix]

Thanks for the feedback.

In parallel, we should absolutely try to upstream the Miri integration into official rules_rust. I agree that this is the right long-term direction. Realistically, though, I expect this to take quite some time — likely many months, possibly around a year — because proper Miri support requires non-trivial changes.

That said, I think we need to be careful with the assumption that Miri can be enabled in the same way as C++ sanitizers via a global build option such as --config=ubsan.

Miri is not just another compiler flag or sanitizer. It is a separate interpreter/executor for Rust programs. It also has important limitations, especially around FFI. Because of that, we cannot simply run it over the whole code base and all tests in the same way we run sanitizer-enabled C++ tests.

This is also why the current implementation wraps existing rust_test and rust_binary targets instead of trying to inject Miri globally at compile time.

Another important point: the official Miri documentation states that invoking the Miri driver directly is not a supported interface. Making this work in Bazel, while decoupling it from Cargo/cargo-miri and keeping it hermetic and reproducible, required quite some effort.

There have also been several attempts in the rules_rust community to integrate Miri support, but they were abandoned. So while I fully agree that upstream support is the ideal end state, I do not think we should block practical usage in S-CORE on that.

Also, nobody is forced to integrate Miri targets everywhere immediately ( communication included - you can just drop this PR). We can introduce them where they make sense and expand usage gradually, especially for Rust code that is suitable for Miri and does not depend on unsupported FFI behavior.