Accept any type as the key of the downloader actor

[rina23q]

Proposed changes

This change is required for c8y-mapper's enhancement to download a file per an operation. For example, if the key is only string, it's difficult to distinguish which operation (software, firmware, config_update) fires the download request.

So, this kind of example usage will be possible with this change, sending DownloadRequest:

struct DownloadKey {
    op_type: OperationType,
    id: String
}

self.message_box
    .download_sender
    .send((DownloadKey{ op_type: OperationType::ConfigUpdate, id: "abcd1234".into() }, download_request))
    .await?;

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

#2292

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

Merging #2291 (9bdfdc7) into main (300c43d) will decrease coverage by 0.5%.
The diff coverage is 90.6%.

❗ Current head 9bdfdc7 differs from pull request most recent head dc2bf1a. Consider uploading reports for the commit dc2bf1a to get more accurate results

Additional details and impacted files

Files	Coverage Δ
...rates/extensions/tedge_downloader_ext/src/actor.rs	79.6% <50.0%> (-1.3%)	⬇️
...rates/extensions/tedge_downloader_ext/src/tests.rs	93.4% <92.6%> (-0.4%)	⬇️

... and 16 files with indirect coverage changes

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
294	0	3	294	100	1h1m53.959s

[didier-wenzek]

Approved

[albinsuresh]

Although I've got nothing against making the Downloader accept generic types as request keys, I fail to get the benefits from the mapper side.

The mapper already had to send a unique operation_id to trigger a download from this actor and hence the mapper already would have known what kind of operation_type it generated that unique id for. The mapper was already caching that ID in the reqs_pending_download map and it could have just added the OperationType info as well into this map. Instead, here we are sending that info to the downloader, which does nothing with that additional info, essentially using the downloader as that cache, whereas we could have simply extended the reqs_pending_download map for the same. Or did I miss something else here?