Init command JSON output

[metalsp0rk]

What does this PR change? What problem does it solve?

Enablement of JSON output on the init command.

Was the change discussed in an issue or in the forum before?

Fixes #3124

Checklist

• I have read the Contribution Guidelines
• I have enabled maintainer edits for this PR
• I have added tests for all changes in this PR
• I have added documentation for the changes (in the manual)
• There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
• I have run gofmt on the code in all commits
• All commit messages are formatted in the same style as the other commits in the repo
• I'm done, this Pull Request is ready for review

[MichaelEischer]

I've added a few minor comments to the PR. However, there's one point which requires discussion: All other places in restic just return the standard error message when an error happens and don't encode those as JSON. It might for now be better to stay consistent with the other commands.

[metalsp0rk]

there's one point which requires discussion: All other places in restic just return the standard error message when an error happens and don't encode those as JSON. It might for now be better to stay consistent with the other commands.

So my rationale here is that it would benefit us to output errors as a JSON object because if a wrapper script is expecting JSON output, the script will not be able to easily handle non-JSON output errors. Of course, it could just panic and alert the user, but in some cases, issues that cause failure could be automatically solved by a wrapper script.

I'm okay with staying consistent with other commands for now. Maybe roll those error handling changes into another PR if we decide we want that, down the line.

[metalsp0rk]

I'm ready to merge this. Can I get another review on this?

[MichaelEischer]

I'm ready to merge this. Can I get another review on this?

I totally forgot about this PR. It's now rebased and slightly cleaned up. The status field is now called message_type as that is also used to identify the message type in other places.

The remaining part is to decide on a message_type name. Right now, it is repository_created, although something shorter like summary might also be suitable.

[MichaelEischer]

LGTM.