Follow up tasks for built-in bridge

[jarhodes314]

In #2716, support was added to the mapper for a built-in Cumulocity bridge, to replace the mosquitto-based bridge.

Here is a list of follow up tasks that need completing before the feature is fully complete and ready to be enabled for users:

• [ ] Don't drop messages published when the mapper is down (see https://github.com/thin-edge/thin-edge.io/pull/2716#discussion_r1526243685 for a test case)
• [x] Support non-c8y clouds
• [x] Ensure custom templates work This appears to just work. I added a custom template ID to tedge config, restarted the mapper, and created the template in the Cumulocity UI and the mapper was forwarding messages received to c8y/s/uc/my-template-id. There were no issues with subscribing to the template topic before the template existed, as I hoped would be the case. Deleting the template in the UI didn't stop Cumulocity from sending the template messages, although this is clearly a Cumulocity behaviour, and not within our control, even if it does seem a bit weird.
• [x] Make mapper bridge health message look like other messages
• [x] Fix connectivity check in tedge connect c8y
• [x] Ensure status is reported as "up" after restarting local broker
• [x] Fix bridge health topic filtering (https://github.com/thin-edge/thin-edge.io/pull/2810#discussion_r1549914042)
• [ ] Use the custom topic prefix in the tedge-mapper-c8y service name
• [x] Custom topic prefix validation
• [x] Various TODOs left in code in the original PR (to be expanded as notable ones are encountered)
• [ ] Documentation
• [x] Make the associated configurations visible, both in tedge config list and tedge config list --doc
• [ ] Remove the feature flag and enable the feature by default

[jarhodes314]

I've been looking at making the logic work for tedge cert create and have hit a bit of an issue. In the case of the built-in bridge, we want the device certificate to be owned by tedge, but in the mosquitto bridge, the device certificate should instead be owned by mosquitto. At the moment, the configuration for the bridge is c8y.bridge.built_in, implying that this setting is per-cloud, but since only one of mosquitto or the mapper should be able to read the cert/key at a time, it isn't actually possible to have this setting work differently for different clouds.

@didier-wenzek @reubenmiller do you think it's reasonable to change the setting to bridge.built_in (or some other name), or do you have other suggestions as to how to resolve this?

[didier-wenzek]

I've been looking at making the logic work for tedge cert create and have hit a bit of an issue. In the case of the built-in bridge, we want the device certificate to be owned by tedge, but in the mosquitto bridge, the device certificate should instead be owned by mosquitto. At the moment, the configuration for the bridge is c8y.bridge.built_in, implying that this setting is per-cloud, but since only one of mosquitto or the mapper should be able to read the cert/key at a time, it isn't actually possible to have this setting work differently for different clouds.

@didier-wenzek @reubenmiller do you think it's reasonable to change the setting to bridge.built_in (or some other name), or do you have other suggestions as to how to resolve this?

I see different alternatives - none really convincing

1. Having a device certificate per cloud. But how to ensure all these have the same CN? Furthermore, this doesn't really help here when the point is to connect the same cloud (c8y) using two different mechanisms (mosquitto bridge or built-in).
2. Let tedge cert create checks the c8y.bridge.built_in setting (or better as you propose a generic bridge.built_in setting) to assign the appropriate owner to the private key, One might improve the user experience if tedge cert create can also be used to re-assign the proper owner if the setting for bridge.built_in is changed.