Is your refactoring request related to a problem? Please describe.
I accidentally deleted some of the clap completion logic in the code in #3371 and it broke completions. I failed to detect this other than by attempting to complete manually due to the lack of a system test for the completions.

I didn't initially add a system test for completions as it was rather complicated to test. I'm still not sure about how I would go about automating the full process where we type something into a shell, hit tab and then view some results. However, since we are using dynamic completions it is easy to run the "completion generation" script and verify the relevant completions are produced.

Describe the solution you'd like
I think the easiest and clearest way to test this is to manually trigger the fish completions (the bash and zsh ones are more complicated to unpick) and validate the output is what we expect. For example:

$ COMPLETE=fish tedge -- tedge config get sud
sudo.enable      Determines if thin-edge should use `sudo` when attempting to write to files possibly

$ COMPLETE=fish tedge -- tedge --
--config-dir    [env: TEDGE_CONFIG_DIR, default: /etc/tedge]
--debug Turn-on the DEBUG log level
--log-level     Configures the logging level
--help  Print help (see more with '--help')
--version       Print version

I think it's valuable to check that the completions work for configuration keys, since some manual logic is involved there (though we do have a unit test for that). That said, we don't want the test to be too brittle and fail as soon as we change the documentation for a key/add a key. I think the sudo example above is probably not a bad one to use.

It may also be worth verifying the following as that has some manual logic:

$ COMPLETE=fish tedge -- tedge mqtt pub --qos ''
0       At most once
1       At least once
2       Exactly once