Consistent handling of thin-edge.io services topic ids

[Bravo555]

Is your refactoring request related to a problem? Please describe.

Currently, most of our thin-edge services obtain their MQTT service topic ids by deriving it from the device topic id if it's in the default scheme, and failing if it's not in the default scheme:

thin-edge.io/plugins/tedge_configuration_plugin/src/lib.rs

Lines 105 to 118 in d60c3b7

	// TODO: take a user-configurable service topic id
	let mqtt_device_topic_id = mqtt_device_topic_id.parse::<EntityTopicId>().unwrap();
	let service_topic_id = mqtt_device_topic_id
	.to_default_service_topic_id(PLUGIN_NAME)
	.with_context(|| {
	format!(
	"Device topic id {mqtt_device_topic_id} currently needs default scheme, e.g: 'device/DEVICE_NAME//'",
	)
	})?;
	let service = Service {
	service_topic_id,
	device_topic_id: DeviceTopicId::new(mqtt_device_topic_id.clone()),
	};

This behaviour means that the user effectively can't set their own custom device topic scheme, because then all the thin-edge services would be unable to start. To effectively support custom MQTT schemes, the services have to come up with a service topic id in all cases.

Describe the solution you'd like

The solution would have to be:

• working for any device: create valid service topic id for services running on a main device, child device, or a nested child device
• handle registration: besides the service topic id, the service also has to obtain a registration message
• centralised: a single API for services to call to obtain their service topic id
• simple to use, hard to misuse: should require little (if any) additional code in callers themselves, so it's not a pain to do a correct thing

Service topic id generating mechanism

As for the mechanism for generating service topic id, @albinsuresh proposed to create a default scheme topic id using device.id as DEVICE_NAME in device/DEVICE_NAME/service/SERVICE_NAME, but it only works for main devices. We can perhaps reduce the device hierarchy down to a single DEVICE_NAME by combining names using a join, but then we need to be careful to only join using characters which can't appear in a device name.

This aspect will require more discussion to find the simplest complete solution.

How it will be used by the clients

As for how this will be used by services: generating an MQTT topic id and an MQTT registration message should be handled by actors which use MQTT directly. That way, the entity does not even need to be aware of what the device topic id is, what its own topic id is, or even what is the MQTT topic root, both this and #2357.

[didier-wenzek]

For a proposal, see #2253 (comment)

[Bravo555]

• derive the service topic identifier of the daemon from mqtt.device_topic_id assuming a default MQTT schema,
  when no mqtt_service_topic_id is given
• stop with an error when the service topic identifier is not given and cannot be derived.

I think this would be very limiting if tedge daemons could not start because mqtt.device_topic_id does not fit a default scheme, but if implemented, would be better than what we have now, because at least it could be consistent between all the daemons. All the mqtt_topic_root, mqtt_device_topic_id and mqtt_service_topic_id options should be defined in a single place and used by all the daemons.

[didier-wenzek]

I think this would be very limiting if tedge daemons could not start because mqtt.device_topic_id does not fit a default scheme

It seems that there is some confusion.

I propose to let the daemon stop if the service topic id is neither provided on the command line nor derivable from the device topic id.

[Bravo555]

I propose to let the daemon stop if the service topic id is neither provided on the command line nor derivable from the device topic id.

I meant that it would be limiting if we would only device service topic id from device topic id if device topic id fits default scheme.