Simplify the operation handling code

[Bravo555]

Is your refactoring request related to a problem? Please describe.

As originally described in the Further Comments section in the PR about using the File Transfer Service for log and config operations, the current architecture of the C8y mapper actor adds unnecessary complexity to the operation handling code, by:

• spreading the execution of the operation between many different functions, making it harder to locally reason about the code
• needing additional variables to keep the state necessary for handling of the operations, read by the different functions that run at different stages of the operation lifecycle

This:

• introduces additional friction when making changes to operation handling, because one needs to update multiple functions that each handles a part of the operation's lifecycle, and the signature of the data being passed between these functions, frequently adding additional fields
• mixes levels of abstraction: the actor needs to be aware of the different operations so that it can invoke correct functions to continue handling them

It concerns mainly the interaction between downloader and uploader actors, where every time we need to download/upload from within the operation, we need to send the request and return, in order not to block handling of other things.

Describe the solution you'd like

The preferred solution would be to handle the entirety of an operation in a module dedicated to that operation, without returning, saving state, and relying on other parts of the code to continue the execution. We should be able to run the future that handles the operation concurrently, as that's what async/await should allow.

This was already done for c8y_firmware_manager (#2600), now the aim would be to do something similar with c8y_mapper_ext and its operation handling.

Describe alternatives you've considered

Additional context

[Bravo555]

#2909 eliminated the biggest problems with operation handling, but there are still some big improvements to do:

Follow-up tasks:

• add tests confirming that new requests are still processed and mapped while file downloads/uploads are ongoing (refactor: Simplify the operation handling code by replacing fragmented control flow with regular async/await #2904 (comment))
• stop relying on MQTT echoing back operation clearing message to remove it from OperationConverter (refactor: Simplify the operation handling code by replacing fragmented control flow with regular async/await #2904 (comment))
• ensure panics are consistently propagated from OperationHandler to the actor as soon as possible
• separate operation handling business logic from low-level messaging/task management (try implementing OperationHandler as a separate actor)
• remove IdGenerator from software_update.rs
• clean up Operation API
  • generate topic clearing messages once for all operations
  • introduce an "Operation" abstraction layer that decouples it from our MQTT API
• split off more Operation-related things from CumulocityConverter
  • operations
  • children
  • operation_logs
  • active_commands
• add more tracing coverage

Additional checks:

• test that uploaded logs are correct and aren't being uploaded multiple times
• ensure that message duplicates are not processed multiple times (don't process operation status duplicates #3053)