Expose first-party errors on console

[tjkirch]

This uses simplelog's TerminalMode::Mixed to send errors to stderr and other output to stdout. (It's also configurable in other interesting ways if we need.) Then it exposes errors on the console through systemd's StandardError setting.

This is only done on first-party code where we control the error messages. We don't want to do this for third-party code that could spam the console; there's a performance impact for every message.

Related: as part of moving to simplelog, I clarified the confusion around number of -v arguments by switching to an explicit --log-level argument, e.g. --log-level info, which is the default.

Testing done:

With a normal "healthy" launch, only one additional message was output, from updog, and it's something that should be output. (We've since updated timestamp.json in the repo.)

updog[3779]: Metadata error: timestamp metadata is expired

If I have a fake setting like this in user data:

[settings.host-containers.admin]
enabled = true
fakesetting = "sup"

Then I get a moondog error in console:

moondog[2891]: Error: APIResponse { method: "PATCH", uri: "/settings", code: 400, response_body: "Json deserialize error: unknown field `fakesetting`, expected one of `source`, `enabled`, `superpowered` at line 1 column 57" }

You can see that it's the display representation of one of our error types that was printed before exiting moondog unsuccessfully.

Similarly, if I have invalid TOML in the user data:

moondog[2891]: Error: TOMLUserDataParse { source: Error { inner: ErrorInner { kind: Unexpected('/'), line: Some(5), col: 19, at: Some(111), message: "", key: [] } } }

If I run in qemu, we can see a couple more - updog and sundog failing because settings couldn't be generated:

[   60.098175] updog[2438]: Failed to read config file /etc/updog.toml: No such file or directory (os error 2)
[   96.355425] sundog[2372]: Error: FailedSettingGenerator { program: "pluto pod-infra-container-image", code: "1", stderr: "Error: ImdsRequest { path: \"/dynamic/instance-identity/document\", source: Error(Io(Custom { kind: TimedOut, error: \"timed out\" }), \"http://169.254.169.254/2018-09-24/dynamic/instance-identity/document\") }\n" }

Beyond those common cases... we don't actually have many error-level logs in our first-party code yet. This gives us the opportunity to add meaningful ones, though. And the types of errors we do get (in testing above) should be a big help to the debugging cases we've seen so far.