Refactor config commands

[polldo]

Motivation

the old way of creating a configuration file was problematic from the security point of view: secrets should not be taken as input parameters.
< read the edited README for more details>
With this PR, the config command is changed into config init. Secrets cannot be passed anymore as input parameters.
Instead, this new command create a skeleton to be manually filled:
$ iot-cloud-cli config init --overwrite --dest-dir <destinationFolder> --config-format <json|yaml>
It allows to specify a directory in which the configuration file will be initialized.
Also, the optional overwrite flag indicates that if a config file already exists in that folder, it will be overwritten.
Moreover, the configuration file can be written in both json and yaml format.

Change description

Additional Notes

Reviewer checklist

• PR address a single concern.
• PR title and description are properly filled.
• Changes will be merged in main.
• Changes are covered by tests.
• Logging is meaningful in case of troubleshooting.
• History is clean, commit messages are meaningful (see CONTRIBUTING.md) and are well formatted.

[zmoog]

@polldo I like this new design of the config command: the previous was 'ok' but this one is better, 👍 for me here.

That said, I also have a couple of comments using the CLI.

Message After Init (minor)

If I run the following command:

$ iot-cloud-cli config init
$ 

The prompt just returns without any message. It's probably OK, I'm just wondering if a message like "Configuration file created at ./arduino-cloud.yml" would be helpful, or just noise 🤔

$ iot-cloud-cli config init
> Configuration file created at ./arduino-cloud.yml

Global Config (idea for the next iteration)

As a command line user, I usually prefer having a sensible default configuration and a global config file to override those settings (other tools, like the AWS CLI, go the extra mile and support multiple named configuration settings — profiles — but this is probably overkill for the Cloud CLI, at least in this phase).

For example, in my personal ideal scenario if I run a iot-cloud-cli I would expect it to silently lookup behind the scenes into default path like ~/.arduino/cloud.yml and apply it. I should also offer an override mechanism like iot-cloud-cli --config /another/path/cloud.yml.

[zmoog]

Another (sort of minor) comment, because I am becoming quite picky about PR description 😇

Your PR contains a lot of helpful information, but IMO it is harder to read than necessary. My personal suggestion is to group the content by "Motivation" (the WHY you're proposing this change) and the "Change description" (the WHAT you're changing and HOW).

[polldo]

Your PR contains a lot of helpful information, but IMO it is harder to read than necessary. My personal suggestion is to group the content by "Motivation" (the WHY you're proposing this change) and the "Change description" (the WHAT you're changing and HOW).

@zmoog Thanks a lot for the suggestion, I'll do my best to improve

The prompt just returns without any message. It's probably OK, I'm just wondering if a message like "Configuration file created at ./arduino-cloud.yml" would be helpful, or just noise

That's a decision we made in this PR . Does it make sense for you?

For example, in my personal ideal scenario if I run a iot-cloud-cli I would expect it to silently lookup behind the scenes into default path like ~/.arduino/cloud.yml and apply it. I should also offer an override mechanism like iot-cloud-cli --config /another/path/cloud.yml.

It would be really nice, we should add this improvement to the backlog!

[zmoog]

That's a decision we made in this PR . Does it make sense for you?

My bad, I didn't read carefully enough this pull request.

I agree with the philosophy, so 👍 for me!

[glumia]

Added just two comments for possible improvements, but overall it looks good to me!

I agree with @zmoog that it would be nice to have a default global configuration for the tool (eg. in ~/.config/iot-cloud-cli on Linux/MacOS and in %APPDATA%\iot-cloud-cli on Windows) and the possibility to specify the full path to the file to generate (not just the directory) or to load as config. We could open an issue here or on Jira to track it and eventually do it in the future.