Describe the bug
In order for the tedge-mapper-c8y status to be set to down in Cumulocity, two things need to happen:

1. The service_monitor_actor publishes the 102,... last will message to c8y/s/us
2. The bridge receives forwards this message to Cumulocity

Previously when shutting down the mapper, the service status for tedge-mapper-c8y was accurately reported as down since the bridge was running separately in mosquitto. With the built-in bridge, however, it's hit or miss whether the bridge fully processes the message before shutting down. As a result, I modified the Cumulocity bridge's last will message to include a down message for both tedge-mapper-bridge-c8y and tedge-mapper-c8y. This fixes the mapper status reporting, ensuring that tedge-mapper-c8y is marked down in Cumulocity when the mapper is stopped.

The unintentional side-effect of this is that tedge-mapper-c8y is also reported as down whenever the bridge disconnects from Cumulocity, e.g. due to network flakiness. When the bridge reconnects, it updates its own health status to be up, but doesn't update the health status of tedge-mapper-c8y since the rest of the mapper is blind to the disconnection the bridge suffered, therefore tedge-mapper-c8y remains marked as down in Cumulocity until the mapper is restarted.

To Reproduce

• Run the Cumulocity mapper with the built-in bridge enabled
• Observe that both tedge-mapper-c8y and tedge-mapper-bridge-c8y are marked as up on the cloud device
• Disconnect from the internet and wait for the bridge to log that it has disconnected from the cloud
• Observe that both tedge-mapper-c8y and tedge-mapper-bridge-c8y are marked as down on the cloud device
• Reconnect to the internet and wait for the bridge to log that it has reconnected
• Observe that tedge-mapper-c8y is still marked as down on the cloud device

Expected behavior
tedge-mapper-c8y should not continue to be marked as down once the bridge has reconnected.

Screenshots