CLI: Rework cmpInstanceKeys for contextual completions based on instance type

[kadinsayani]

Fixes #14689.

Summary of changes:

• (WIP) Adds completions for cloud-init.* config keys.
• (WIP) Correctly provides completions based on instance type.

[tomponline]

this looks fishy, whats it comparing to?

[kadinsayani]

The condition field for a cloud-init.* instance config key:

			"cloud-init": {
				"keys": [
					{
						"cloud-init.network-config": {
							"condition": "If supported by image",
							"defaultdesc": "`DHCP on eth0`",
							"liveupdate": "no",
							"longdesc": "The content is used as seed value for `cloud-init`.",
							"shortdesc": "Network configuration for `cloud-init`",
							"type": "string"
						}
					},

Alternatively, we could add all keys under the cloud-init map.

[tomponline]

why are we needing to consider the Condition field?

[kadinsayani]

We check the condition field to determine if a key is valid for instance type any, container, or virtual-machine.

[tomponline]

ok, so we really dont want to be comparing to arbitrary free-text values.

This seem super hacky to me.

[kadinsayani]

I'm in agreement with moving away from checking "condition" values.

But that would then be restricted to keys known about by the client, and not by the server leading to situations where the client may suggest something the server doesnt support or miss out on suggesting something it does support.

We can also consider checking the keys from the metadata API against instancetype.InstanceConfigKeysAny/VM/Container to deduce compatible instance types. Aren't the keys generated by lxd-metadata sourced from lxd/instance/instancetype/instance.go?

[tomponline]

Yes, but remember lxc would be built against a list at a point in time, but the server maybe newer and have additional keys only in metadata api

[kadinsayani]

What about adding a "supported instance type" field to the metadata? I'm trying to avoid hard coding a list of accepted keys based on instance type in the client, since these may not line up with the server. Also, there are cases where a prefix contains keys supported by containers and VMs. For example, the migration prefix contains migration.incremental.memory which is only supported by containers, and migration.stateful which is only supported by VMs.

[kadinsayani]

Another consideration for adding an instance type field to config keys in the metadata is the potential usability improvements that could be achieved in lxd-ui. I don't use it much so I'm not sure if completions are served when setting profile or instance config keys, but having an instance type field in the metadata could facilitate smart completions for config keys in the ui.

[kadinsayani]

Another option could be including the condition metadata string with the completion results in brackets. For example:

$ lxc config set c1 [TAB]
limits.cpu.pin_strategy (virtual machine)
cloud-init.network-config (If supported by image)
...

With this option, we effectively mirror the documentation and inform users of all available configuration keys and their corresponding condition (virtual machine only, unprivileged container, if supported by image, storage volumes managed by LXD, etc.)

cc. @simondeziel

[tomponline]

Is it possible to split this pr into two, so we can merge the non contentious parts?

[kadinsayani]

Is it possible to split this pr into two, so we can merge the non contentious parts?

Sure thing. I've updated this PR and created #14702. Please note the addition of 5b7d222.