refactor: support writable device ids

[jarhodes314]

Proposed changes

This adds support for a writable device ID to aid @rina23q's work. I'm marking this as a refactoring as it doesn't really perform the task in itself, although I have modified tedge_config.rs to use the new feature for verifying it actually works as intended.

Still TODO:

• Support a default value, so c8y.device.id defaults to device.id
• Make the device ID logic actually do something useful
• Check the test names are appropriate
• Make config.device.id() private

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[rina23q]

If device.id is set (= the value exists in dto), the value should be returned. It should be something like below. This applies to all functions for each cloud (c8y, az, aws).

Suggested change

	device_id_from_cert(&device.cert_path)
	match device.id.or_none() {
	Some(id) => Ok(id.to_string()),
	None => device_id_from_cert(&device.cert_path)
	}

[didier-wenzek]

I do think that the tedge config macro alone cannot solve the complexity introduced by this idea to have cloud specific device identifiers, especially when combined with identifiers that are either explicitly set by the user or derived from certificates.

The tedge cli will have to be updated to enforce that the device identifier for a given end-point is clearly defined without conflicting settings. For example, the following scenario must be prevented:

• tedge config set device.id xxx
• tedge config set device.cert_path cert-with-cn=yyy

[didier-wenzek]

Suggested change

	/// Identifier of the device within the fleet. It must be globally
	/// unique and is derived from the device certificate.
	/// Identifier of the device within the fleet.
	/// Derived from the device certificate if there is one.
	/// Used for all cloud end-points unless explicitly superseded.

[didier-wenzek]

Suggested change

#[tedge_config(note = "This setting is derived from the device certificate and is therefore read only.")]

[didier-wenzek]

Suggested change

	/// Identifier of the device within the fleet. It must be globally
	/// unique and is derived from the device certificate.
	/// Identifier of the device for this cloud end-point.
	/// Derived from the device certificate if there is one for this end-point.
	/// Default to the global device id, unless explicitly superseded.

[didier-wenzek]

Can this default value simply encoded in the reader function (aka c8y_device_id)?

I even wonder if there is such a default value, the rules being complex:

• derived from the cloud specific device certificate if any
• or read from the cloud profile config if set
• or derived from the global device certificate if any
• or read from the config if set

[rina23q]

I was also thinking that the default from device.id will work partially. This is the scenario which doesn't work.

c8y.device.cert_path and device.id exists, but c8y.device.id is missing. Then, I expect c8y.device.id will return the CN of the c8y.device.cert_path. However, my guess the config will return the value of device.id due to the default.

[rina23q]

c8y.device.cert_path and device.id exists, but c8y.device.id is missing. Then, I expect c8y.device.id will return the CN of the c8y.device.cert_path. However, my guess the config will return the value of device.id due to the default.

As we discussed today, this is a corner case. It's fine that c8y.device.id returns the value of device.id instead of its CN. We just have to document that user should set c8y.device.id explicitly in that case.