Refactoring: shorten module names, remove some modules

[ivmarkov]

This work is addressing module name issues described in #173.

While #233 and #237 did address the module names of the system clusters, and the system handlers' names themselves, these PRs did not touch the "more generic" module names, so to say, which this PR addresses.

The PR is very large as it is mostly automated work.
It cannot be reviewed line by line (obviously). Instead, I've tried to keep it as a series of separate commits, where each commit resulted in a type-checking, tests-passing outcome, and each commit is kind of self-describing as to what was the refactoring change.

Additionally, I provide a summary of the changes below:

mod.rs is gone from the codebase

Previously, the older modules used the older mod.rs pattern, while the newer ones used the newer style (i.e. foo is in foo.rs and then foo/ contains sub-modules only.

Now everything except one single module in tests/ is using the newer pattern.

core is gone

Older rs-matter modules used a slightly less idiomatic pattern mentioned in #173, where bigger modules, like - say - transport - or even the root module - contained only sub-modules, while the "meat" of - say - the transport module - was present in transport::core instead.

Since folks find this a bit less idiomatic, and because core is - well - known as Rust's core library, I've merged all core submodules into their parents, i.e.:

• rs_matter::core is now simply rs_matter (and thus no longer rs_matter::core::Matter but just rs_matter::Matter
• rs_matter::transport::core -> rs_matter::transport
• rs_matter::sc::core -> rs_matter::sc
• rs_matter::im::core -> rs_matter::im
• rs_matter::dm::core -> rs_matter::dm

interaction_model -> im, data_model -> dm, secure_channel -> sc

This is probably the one change where I have second thoughts.

While Interaction Model and Secure Channel are commonly abbreviated in the Matter spec as IM and SC respectively - and - some constants in our codebase still carry a SC* / IM* prefix, these module names are a tad too short.

On the other hand, interaction_model and data_model and secure_channel are way too long, and they tend to be imported a lot. So I'm not 100% sure we should go with the abbreviated names, but I don't have better ideas for just slightly longer but more descriptive names either.

If you have suggestions, I'm all ears!

All cluster-meta-data and handler implementations moved to rs_matter::dm::clusters

Previously, some of the system clusters were in something called rs_matter::dm::sdm (sdm?). Others were is rs_matter::dm:system_model. A few were directly in rs_matter::dm. I think it is just simpler to move all of these into rs_matter::dm::clusters, and anyway 95% of these are "system" clusters necessary for the operation of rs_matter anyway. The two exceptions are:

• unit_testing - we might move it to tests/ in future, but until we implement [TESTS] End-to-end tests #187 I would refrain from that
• on_off - which is used in the examples only

Similarly, I've renamed rs_matter::dm::device_types to rs_matter::dm::devices and rs_matter::dm::root_endpoint to rs_matter::dm::endpoints to align with rs_matter::dm::clusters.

Misc

A non-exhaustive list of smaller changes:

• rs_matter::codec moved to rs_matter::utils::codec as it is independent of the rest of the rs_matter codebase. The rule for utils is: everything which is not Matter-specific lives in utils. As in our pin-init re-exports, our pin-init-aware containers, etc. etc. codec contains a single module for doing base38 serde hence it should live in utils;
• sc::common and sc::status_report moved to just sc. So we finally have a symmetry between i.e. im::OpCode and sc::OpCode;
• im::messages and im::core::ib moved to im directly. Just like im::core. If im gets larger in size, we can always split bits and pieces back to separate, private sub-modules which are still re-exported with pub use private_submodule::*; in the im namespace, for end-user simplicity, just like we do for rs_matter::tlv and for rs_matter::dm::types (see bullet point below for the latter);
• dm::objects renamed to dm::types and made private, and then re-exported in the dm namespace directly, as the objects thing is too big to just be lumped as one big chunk of code in dm). I don't think rs_matter::dm::objects::Handler or rs_matter::dm::objects::Cluster or rs_matter::dm::objects::Attribute were meaningful. What is an "object" in the first place? (And yes, guilty as charged, as I think I introduced the "objects" module and sub-modules long ago). Also, these things are such a basic notion of the Data Model, that they deserve to live - from the perspective of the user - in the root of the Data Model anyway, i.e. directly under rs_matter::dm;
• rs_matter::crypto::crypto_mbedtls, rs_matter::crypto::crypto_rustcrypto (gotta love the 3-legged tautology!) and the rest of these are now (a) shortened to just rs_matter::crypto::mbedtls, rs_matter::crypto::rustcrypto and (b) are now private modules, where exactly one of these (depending on the activated crypto-provider) is re-exported as just rs_matter::crypto;
• Similarly, in rs_matter::sc which has its own little crypto-extension story, rs_matter::sc::crypto_mbedtls, rs_matter::sc::crypto_rustcrypto and so on were re-named as rs_matter::sc::crypto::mbedtls, rs_matter::sc::crypto::rustcrypto and so on and also re-exported as just rs_matter::sc::crypto

I'm sure I'm missing a few smaller changes, but hopefully the above covers the major stuff.

[gemini-code-assist]

Summary of Changes

Hello @ivmarkov, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant internal refactoring of the rs-matter crate, focusing on simplifying module names and reorganizing the codebase for improved clarity and maintainability. The changes aim to make the project structure more intuitive by grouping related components under concise, top-level modules, without altering the external API behavior.

Highlights

• Module Renaming and Shortening: The primary refactoring involves shortening top-level module names: data_model is now dm, secure_channel is sc, and interaction_model is im. This change is applied consistently across the entire codebase, including examples, macros, and the core library.
• Core Component Relocation: The Matter struct and MATTER_PORT constant, previously residing in rs-matter/src/core.rs, have been moved directly into rs-matter/src/lib.rs. Similarly, the main transport logic from rs-matter/src/transport/core.rs is now in rs-matter/src/transport.rs.
• Consolidated Functionality: Various related functionalities have been consolidated. For instance, Interaction Model (IM) and Secure Channel (SC) message definitions are now in dedicated im.rs and sc.rs files respectively. Device attestation constants and vendor identifiers have also been moved to more central locations within the dm and pairing modules.
• Dependency Path Updates: All internal use statements and code references have been updated to reflect the new, shorter, and reorganized module paths. This includes paths to clusters, objects, devices, networks, and various protocol components.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request primarily focuses on refactoring module paths within the rs-matter crate, aiming to shorten module names and reorganize the structure. Key changes include renaming data_model to dm, interaction_model to im, secure_channel to sc, and moving several core components like Matter to the crate root. Most of the changes are consistent path updates in use statements and code.

I've identified two critical issues related to incorrect import paths for BasicInfoConfig in the mdns module, which will likely lead to compilation errors. The rest of the refactoring appears consistent.

[bjoernQ]

Thanks for making this as reviewable as possible.

I'm not a big fan of two-letter abbrevs but I honestly don't have a reasonable alternative suggestion to them. Tried to look into what e.g. matter-js is doing but that didn't help really

In any case it's good to have these changes consolidated in one PR w/o any functional changes (in contrast to doing it whenever someone runs into a piece of code when implementing a functional change)

[ivmarkov]

Thanks for making this as reviewable as possible.

I'm not a big fan of two-letter abbrevs but I honestly don't have a reasonable alternative suggestion to them. Tried to look into what e.g. matter-js is doing but that didn't help really

In any case it's good to have these changes consolidated in one PR w/o any functional changes (in contrast to doing it whenever someone runs into a piece of code when implementing a functional change)

Well, the promise in #173 was that the big refactorings related to it would be just renames/moves. If you look at the downstream crates (PRs linked above), the only changed thing is a bunch of use statements.

As for the dm, im and sc... yeah. Open to any other suggestions.
On the other hand, if you look downstream, 60%-70% of what is imported from rs-matter is from the dm module, so a shorter name does definitely help.

[ivmarkov]

@kedars Would be interested in your feedback as well. Will wait a few days before merging therefore.

[bjoernQ]

On the other hand, if you look downstream, 60%-70% of what is imported from rs-matter is from the dm module

Yes, that's what I figured - I guess otherwise it's a fair assumption that anyone working on the code base is aware what these names mean