Describe the bug

When deregistering a thin-edge.io entity via the Entity Management HTTP API, any retained MQTT messages (e.g. {root-prefix}/{topic-id}/status/health, {root-prefix}/{topic-id}/a/{type}) published to the device already are not removed. This can result in the entity auto-registering itself again due to these retained message if the tedge-agent service is restarted.

To Reproduce

1. Register a new service using the HTTP API

   tedge http post /te/v1/entities '{"@type":"service","name":"foo","@topic-id":"device/main/service/foo"}'

2. Publish some retained messages to the service to update the service status and add an alarm

   tedge mqtt pub -r -q 1 te/device/main/service/foo/status/health '{"status":"up"}'
   tedge mqtt pub -r -q 1 te/device/main/service/foo/a/bar '{"severity":"major"}'

   Afterwards, you can check which MQTT messages are related to the service on the local MQTT broker:

   $ tedge mqtt sub 'te/device/main/service/foo/#'
   
   [te/device/main/service/foo/a/bar] {"severity":"major"}
   [te/device/main/service/foo/status/health] {"status":"up"}
   [te/device/main/service/foo] {"@type":"service","name":"foo"}

3. Deregister device using the HTTP API

   tedge http delete /te/v1/entities/device/main/service/foo

4. Check the local MQTT broker to see if all message related to the service have been removed

   tedge mqtt sub 'te/device/main/service/foo/#'

Extended process showing that a device is registered again after restarting the tedge-agent

5. Using go-c8y-cli, delete the service from Cumulocity

   c8y devices services delete --device 12345 --id foo
   

6. On the device again, restart the agent

   sudo systemctl restart tedge-agent

   Check in the Cumulocity Device Management to see if the service has been recreated (due to the service's retained messages not being cleared during registration)

Expected behavior

When an entity is deregistered via the HTTP API (e.g. /te/v1/entities/{topic-id}), then all of the related MQTT messages should be cleared on the local MQTT broker (regardless if the messages are sent via HTTP or MQTT), this includes:

• status messages (/status/health)
• alarms (/a/<type>)
• Any other retained messages matching the topic, {root-prefix}/{topic-id}/#

Screenshots

Environment (please complete the following information):

Additional context