Describe the bug
There are two issues.

1. c8y-mapper ignores any bridge status updates after the initial registration for the services of bridge status is done.
2. c8y-mapper reports the status "up" although the reported bridge status is 0 at registration.

thin-edge supports multi clouds. If both c8y and az bridges are configured, but c8y-bridge is up and az-bridge is down, still c8y-mapper should report the az-bridge service status "down" in the c8y tenant. However, due to the issue 1), after the initial 102 message for the az-bridge service, even though the az-bridge status changed, the change status won't be reported to c8y tenant.

To Reproduce
[in the versions 1.0.0 and 1.0.1]

1. Connect thin-edge to c8y
2. Publish this message.

tedge mqtt pub -r te/device/main/service/mosquitto-az-bridge/status/health 0

Then, you can see these messages on the console running tedge mqtt sub "#". These messages are the proof that the new service mosquitto-az-bridge is registered in the entity store and the service is created in c8y.

[te/device/main/service/mosquitto-az-bridge/status/health] 0
[te/device/main/service/mosquitto-az-bridge] {"@id":"TST_tune_concave_molding:device:main:service:mosquitto-az-bridge","@parent":"device/main//","@type":"service","name":"mosquitto-az-bridge","type":"service"}
[c8y/s/us] 102,TST_tune_concave_molding:device:main:service:mosquitto-az-bridge,service,mosquitto-az-bridge,up

The last message should be down. This is the issue 2).
3. Publish the status up message.

tedge mqtt pub -r te/device/main/service/mosquitto-az-bridge/status/health 1

Then you see nothing in the cosole tedge mqtt sub "#". This is the issue 1). 102 message should be created for mosquitto-az-bridge.

Expected behavior

1. At least other bridges (az, aws, ...) status updates messages from mosquitto should be converted to either SmartREST 102 or 104, and reported to c8y.
2. If the payload of the first bridge status message arrived in c8y-mapper is 0, it should be translated to "down". So, 102 service creation message should have the status down.

Screenshots

Environment (please complete the following information):

• OS [incl. version]
• Hardware [incl. revision]
• System-Architecture [e.g. result of "uname -a"]
• thin-edge.io version [1.0.0, 1.0.1] (1.1.0 is out as it has a different issue bridge status is not published as a service to the cloud in 1.1.0 #2898)

Additional context
I'm not sure if using 102 service creation messages always even to update the service status. This works like HTTP PUT. There is another SmartREST message 104, which is intended to update the service status only.