Support jetson power fan configs

[cywang117]

Support HOST_CONFIG_power_mode and HOST_CONFIG_fan_profile with new PowerFanConfig backend, initially for Jetpack 6 devices. The configs are received in target state and written to config.json, where os services will pick up the changes and apply the configs.

This PR combined with #2382 constitutes the complete power fan config feature.

Change-type: minor

[pipex]

Why was it decided to bother with this? Before, all host config changes would require a reboot. Even if it is not necessary for the fan profile, it doesn't seem worth it the extra complexity just to avoid a reboot in this particular case.

[cywang117]

Rebooting when only changing the fan control runtime config is bad UX for the user as it causes unnecessary disruption to devices as well as storage wear. A host config being tied to something that requires a reboot isn't a very strong tie in my opinion; there certainly exists the concept of a runtime OS configuration even if we don't support it in the Supervisor yet. Some examples of this include swappiness and other kernel runtime parameters via sysctl, network configuration such as iptables, and hardware-specific runtime configs: motor speed, sensor sensitivity, etc..

[pipex]

Why does it cause storage wear? How often do we expect users to be changing the fan control speed?

I agree that there are use cases for changing configurations without a reboot.

I don't think the config variable interface is great for that. Config variables require an API call and a target state pull before the changes are applied, is not an interface made for runtime requirements.

If there is need for such an interface then we should work on that rather than trying to fit the config var interface for a specific use case

[cywang117]

Agreed, I think this feature has exposed some limits of the way we handle configs on top of what we were aware of before.

[pipex]

This breaks the independence between backends, why use the same prefix HOST_CONFIG for these new configurations rather than use something different like HOST_OS which is the way we would distinguish configurations before?

[pipex]

Why not add it to forbiddenConfigKeys instead?

[cywang117]

Not sure about HOST_OS, the only occurrence of that I can see is the HOST_OS_VERSION env var. I'll move to adding to forbiddenConfigKeys instead.

[cywang117]

With latest iteration 52f3258, forbiddenConfigKeys is now separated into forbidden and unsupported keys:

// These keys are not config.txt keys and are managed by the power-fan backend.
private static UNSUPPORTED_KEYS = ['power_mode', 'fan_profile'];
// These keys are config.txt keys, but are not mutable by the Supervisor.
private static FORBIDDEN_KEYS = [
	'disable_commandline_tags',
	'cmdline',
	'kernel',
	'kernel_address',
	'kernel_old',
	'ramfsfile',
	'ramfsaddr',
	'initramfs',
	'device_tree_address',
	'init_emmc_clock',
	'avoid_safe_mode',
].concat(ConfigTxt.UNSUPPORTED_KEYS);
...
public isSupportedConfig(configName: string): boolean {
	return !ConfigTxt.FORBIDDEN_KEYS.includes(configName);
}
public isBootConfigVar(envVar: string): boolean {
	return (
		envVar.startsWith(ConfigTxt.PREFIX) &&
		!ConfigTxt.UNSUPPORTED_KEYS.includes(ConfigTxt.stripPrefix(envVar))
	);
}

The concept of unsupported keys is used by isBootConfigVar to filter out non-config.txt keys, but keep in forbidden config.txt keys such as initiramfs. When isBootConfigVar is called by envToBootConfig in bootConfigChangeRequired, this will allow bootConfigChangeRequired to provide the proper feedback to the user that they're attempting to set a forbidden (but not unsupported) key.

This still isn't ideal IMO, I think isSupportedConfig/isBootConfigVar are a bit redundant in terms of functionality. The config module could be simplified in this regard, but I would save this for another PR.

[pipex]

Seems generally OK, just some questions that relate to the discussion on the project