Consider running (a subset of) Chip's YAML tests with our own e2e integration framework #298
Description
The tests inside rs-matter/rs-matter/tests are actually integration tests.
How they work is that the e2e module starts two separate rs-matter instances, connected over a fake UDP channel (an embassy-sync zerocopy in-process channel actually).
These two rs-matter instances currently come "pre-commissioned" with a fake pair of CASE keys and a ready CASE session (i.e. currently the whole commissioning and mDNS dance is bypassed). This is possible, because the two instances run in-process.
From then on, the first rs-matter instance acts as the client/controller, and the other - as the server.
The controller runs the test cases by firing actual IM requests over the fake UDP channel against the server and then validates the server responses against its expectations.
Basically, a simplistic "YAML" framework in disguise.
It should be possible - by utilizing a YAML parser and then some glue code - to actually run a certain subset of the Matter C++ SDK YAML tests directly in our e2e framework, rather than cloning the connectedhomeip repo, installing a bunch of OS deps, building chiptool and then utilizing the Python-based Matter C++ SDK test harness as #289 did.
Running a subset of the chiptool YAML tests won't invalidate the work done in #289, but would allow us to execute (a critical subset of) the YAML tests as part of our own usual cargo test framework. As our e2e based tests are Rust unit #[test]s in fact. So it would be faster and easier to run.