refactor: Simplify SmartREST publish topics

[albinsuresh]

Proposed changes

While publishing to a nested child device, publish directly to the SmartREST topic
of that device (c8y/s/us/<xid>), without specifying all of all its ancestors.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[codecov]

Codecov Report

Attention: Patch coverage is 87.65432% with 10 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/extensions/c8y_mapper_ext/src/converter.rs	75.00%	0 Missing and 5 partials ⚠️
crates/core/tedge_mapper/src/c8y/mapper.rs	0.00%	2 Missing ⚠️
...ates/extensions/tedge_mqtt_ext/src/test_helpers.rs	0.00%	2 Missing ⚠️
crates/core/tedge_api/src/entity_store.rs	93.75%	0 Missing and 1 partial ⚠️

Additional details and impacted files

📢 Thoughts on this report? Let us know!

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
549	0	2	549	100	1h21m46.009959999s

[didier-wenzek]

Approved - with 2 suggestions.

[didier-wenzek]

A doc comment would be helpful, at least some examples.

Suggested change

	pub fn publish_topic_from_parent(parent: Option<&str>, prefix: &TopicPrefix) -> Topic {
	/// (None, prefix) -> ???
	/// (Some(parent), prefix) -> ???
	pub fn publish_topic_from_parent(parent: Option<&str>, prefix: &TopicPrefix) -> Topic {

[didier-wenzek]

A function name doesn't have to tell the whole story. The signature is enough to understand that this will return None for a device with no parent.

Suggested change

	pub fn parent_xid_if_not_main_device(
	pub fn parent_xid(

[albinsuresh]

Oh yeah, I was kinda expecting some comment on this API, as I really struggled to name it properly. By bad, for not adding the rustdocs for it and hoping that a longer/detailed name would convey it properly.

So, I didn't name it just parent_xid because what's returned is not quite the parent_xid in all cases. For any child devices at level 2 and beyond, this function returns Some(<parent-xid>) as expected. But for the immediate child devices of the main device, where the parent xid is the device id of the main device, this function must return None instead of returning Some(<main-device-id>). We're returning None in that case, because all the existing SmartREST APIs like child_device_creation_message, service_creation_message_payload etc expects None when the message must be published to s/us directly and Some(<parent-xid>) when the message must be published to s/us/<parent-xid>. That's the reason why this function impl has this additional filtering step: filter(|tid| *tid != &self.device_topic_id) to switch it to None when the parent is the main device.

The alternatives were the following:

1. Implement a simple parent_xid function as suggested and call the additional filtering at the places where the SmartREST APIs are used.
2. Update those SmartREST APIs to take the main device xid as an additional parameter and do the filtering there

I implemented it this way it is now, to just have all that logic at one place and reuse it everywhere. But, if that API looks weird, then I can implement one of the above approaches.

PS: Writing so much to explain the API contract, I kinda feel that it was the wrong choice. Option. 2 above may have been a better choice.

[didier-wenzek]

I got it.

Option 2 sounds the correct choice (because moving away the c8y details under c8y_api).

However, it would be better to first stabilize the main PR and add such improvements only in a second step.

For now, simply add this note as a doc comment.

[albinsuresh]

Resolved by 21c694f