Publish registration and capabilities on te topics when connecting to the MQTT broker

[reubenmiller]

Is your feature improvement request related to a problem? Please describe.

If the local MQTT broker (e.g. mosquitto) is not configured with persistence, all retain messages are lost when the service is restarted. As a result all devices registration message, supported commands will not be sent to the platform

1. Start the tedge-agent service (before connection to the cloud)

2. Configure thin-edge.io to connect to Cumulocity IoT (this will al)

   tedge cert create --device-id example001
   tedge config set c8y.url example.c8y.com
   tedge connect c8y

   The tedge connect c8y will also restart the mosquitto broker which will remove all of the previously published retained message by tedge-agent before the tedge-mapper-c8y has seen the messages. This results in the device in the cloud having only partial information about the device.

Describe the solution you'd like

Since registration and device capabilities are fairly critical for other components to understand what the device is and what it can do (e.g. does it accept get/set configuration, software_update, firmware_update command etc.), it might make sense to publish these message every time the component connects to the MQTT broker (and not assume these message are persisted when the MQTT broker is restarted).

Describe alternatives you've considered

Additional context

Below shows an example of the reduced number MQTT message after the MQTT broker is restarted (when it is not configured with persistence).

Before the MQTT broker is restarted, the tedge-agent has previously registered itself and its capabilities:

% tedge mqtt sub '#'
INFO: Connected
[te/device/main/service/mosquitto-c8y-bridge] {"@id":"rmi-macos:device:main:service:mosquitto-c8y-bridge","@parent":"device/main//","@type":"service","name":"mosquitto-c8y-bridge","type":"service"}
[te/device/main/service/mosquitto-c8y-bridge/status/health] 1
[te/device/main/service/tedge-agent] {"@parent":"device/main//","@type":"service","type":"service"}
[te/device/main/service/tedge-agent/status/health] {"pid":66677,"status":"up","time":1715267898.9250402}
[te/device/main/service/tedge-mapper-c8y] {"@id":"rmi-macos:device:main:service:tedge-mapper-c8y","@parent":"device/main//","@type":"service","name":"tedge-mapper-c8y","type":"service"}
[te/device/main/service/tedge-mapper-c8y/status/health] {"pid":61406,"status":"up","time":1715267770.182519}
[te/device/main///twin/c8y_Agent] {"name":"thin-edge.io","url":"https://thin-edge.io","version":"1.0.1"}
[te/device/main///cmd/config_snapshot] {"types":["tedge-configuration-plugin","tedge-log-plugin","tedge.toml"]}
[te/device/main///cmd/config_update] {"types":["tedge-configuration-plugin","tedge-log-plugin","tedge.toml"]}
[te/device/main///cmd/log_upload] {"types":["software-management"]}
[te/device/main///cmd/restart] {}
[te/device/main///cmd/software_list] {"types":["brew"]}
[te/device/main///cmd/software_update] {"types":["brew"]}

After restarting the MQTT broker using systemctl restart mosquitto, the majority of the message are no longer present.

% tedge mqtt sub '#'
INFO: Connected
[te/device/main/service/mosquitto-c8y-bridge/status/health] 1
[te/device/main/service/tedge-agent/status/health] {"pid":66677,"status":"up","time":1715268183.9397252}
[te/device/main/service/tedge-mapper-c8y/status/health] {"pid":61406,"status":"up","time":1715268183.941719}

[reubenmiller]

There are some similarities with this PR, #3462.

In practice, sometimes mosquitto is configured without persistence (maybe accidentally), or persistence is broken due to unexpected changes on the device. Being able to limit the impact of some of these unexpected functionality would make thin-edge.io more resilient.