Improve output format

[polldo]

Motivation

• Allows users to choose an output format between text and json
• Writes to stdout (through fmt.Print..) have been replaced into writes to a logger. If the verbose flag -v is passed to the command line, then the logger will be enabled. Otherwise, all the logs messages will be discarded.

These changes allow users to save results in files. For example, with the following command, a device is provisioned and its properties are written into a json file:
./iot-cloud-cli device create --format json --name <deviceName> > deviceName.json

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.

[glumia]

Hey, I read the changes up to cli/thing/list.go and stopped there because I noticed one main issue: we need to define clearly what we want on stderr and what on stdout and rework the feedback/logs.

We can't just move everything that precedently was printed to stdout to logs, in this way we will stop giving useful feedbacks to users and litter logs with unuseful messages.

Not printing anything to stdout in case of success could be fine if we decide to commit to a "quiet on success/verbose on error" behavior, but in this case we need to be coherent with it on all commands.

On the other hand, stderr (logs) should be used only to print information that could be useful for debugging purposes, because one does not reach for them unless there's some problem.

Update: check below. I missed an important detail about logs not being printed to stderr if the -v is not provided. In our case it makes sense to have detailed logs of what happens.

[polldo]

@glumia
Thanks a lot for the feedbacks

Not printing anything to stdout in case of success could be fine if we decide to commit to a "quiet on success/verbose on error" behavior, but in this case, we need to be coherent with it on all commands.

Yes, this was my goal. In this way the user can save the output of the commands into a file (when it makes sense).
So the behavior should be:

• in case of success without -v flag, print only the useful "data" that the user could save in a file (for example a newly created thing)
• in case of success with -v flag, print everything. here the user cannot expect to save the result in a file without having them "dirtied" by the logs.
• in case of error print the error

Have I not been coherent with it on all commands?

[glumia]

Yes! Sorry I got confused by the default behaviour of discarding logs and of -v both enabling logging and redirecting it to stdout. I had in my mind the classic behaviour of unix tools that always print logs to stderr and normal output to stdout.

Your reasoning makes perfectly sense 👍

As we were talking about in our call we need to just to remove logs when there's already the output of feedbacks and to standardize the formatting of results as text.