Support software type for c8y advanced software management in 10.14

[rina23q]

Proposed changes

Since the version 10.14, c8y starts supporting "type" field for software list and "softwareType" field for software update operation.

Change the Rust code accordingly:

1. Software list
   Stop combining version and software type with the connector "::". The module type will be declared as "type" in c8y JSON and the version field holds its pure version only.

2. Software update
   Different behaviour if a received operation contains "softwareType" field or not. If yes, softwareType will be used as its module type and version will be used as it is. If no, mapper tries to get the module type from the received version field as we initially implemented.

Todo:

• Rust change
• Robot test change
• Doc change

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

#1352

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

All modified and coverable lines are covered by tests ✅

Comparison is base (fb82765) 75.8% compared to head (8bbfa2b) 75.9%.
Report is 11 commits behind head on main.

Additional details and impacted files

Files	Coverage Δ
crates/core/c8y_api/src/json_c8y.rs	90.5% <100.0%> (-0.4%)	⬇️
crates/core/c8y_api/src/json_c8y_deserializer.rs	95.1% <100.0%> (+0.9%)	⬆️

... and 14 files with indirect coverage changes

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
381	0	3	381	100	57m24.674s

[didier-wenzek]

Doc change (need to check)?

Yes, the doc has to be updated.

The sentence "thin-edge.io ships a default plugin supporting debian packages from both apt repositories as well as remote locations. If you prefer to use packages from an apt repository, select the Provide a file path option and give an empty space (' ')." is really unclear.

I would simply tell that if no version or no path are applicable then a string of empty spaces are accepted by thin-edge meaning that this field is non applicable. We can stress that this is the case for the apt plugin when one wants to install the latest version of the package (.i.e. no version) using the package repository configured on the device (i.e. no path/url).

@reubenmiller does it make sense to accept the string "NA" as well as white-spaces to mean that the field is non applicable?

[reubenmiller]

Doc change (need to check)?

Yes, the doc has to be updated.

The sentence "thin-edge.io ships a default plugin supporting debian packages from both apt repositories as well as remote locations. If you prefer to use packages from an apt repository, select the Provide a file path option and give an empty space (' ')." is really unclear.

I would simply tell that if no version or no path are applicable then a string of empty spaces are accepted by thin-edge meaning that this field is non applicable. We can stress that this is the case for the apt plugin when one wants to install the latest version of the package (.i.e. no version) using the package repository configured on the device (i.e. no path/url).

@reubenmiller does it make sense to accept the string "NA" as well as white-spaces to mean that the field is non applicable?

I don't think it is worth it...from an API view, just leaving out the url is fine. I believe the requirement to use whitespace in the url is only a UI form validation issue...so we could put a change request to remove the UI validation to also allow an option to not treat a missing url as an error.

[didier-wenzek]

Approved