Group Cumulocity logic in a `c8y_api` crate

[didier-wenzek]

This refactoring task is part of https://github.com/thin-edge/thin-edge.io/issues/1401.

Motivation

The current code base contains 3 crates (c8y_api, c8y_smartrest and c8y_translator) containing Cumulocity related code, topic names, message payloads, translation functions ... The rationale for this structure is not clear. For instance, where is defined the Cumulocity Json format? Furthermore, many of these Cumulocity related entities are redefined by the mapper (under the tedge_mapper::c8y module) and the operation plugins (c8y_log_plugin and c8y_configuration_plugin). This makes the code difficult to maintain and things can only be worse over time without a share understanding of where to add and search Cumulocity related features.

Proposal

The proposal is to have a single crate, named c8y_api to gather all the definitions of Cumulocity specific entities.

• This crate will contain both the MQTT api (topic names, message payloads) and the REST api (uri, content) as well as the logic (message translations).

  • The crate c8y_api will not define thin-edge related paths or MQTT topics. For instance, the directory for operation configurations will be defined into a tedge_api crate. Same for all the topics used to send operations to the agent.

• The code will be refactored progressively.

  • To start with, we will not define thin-edge related paths in c8y_api.

• Candidate crates and modules

  • tedge_mapper::c8y::converter - remove redefinition of c8y related topics and message payloads
  • tedge_mapper::c8y::fragments - consider moving this entire module in the c8y_api crate
  • tedge_mapper::c8y::topic- consider moving this entire module in the c8y_api crate

[rina23q]

QA check passed, therefore close this issue.