Refactoring of logging

[phillebaba]

Describe what should be investigated or refactored

Test week proved that certain functions are difficult because logging logic is tightly coupled with other logic. For example there are a couple of functions which will print formatted tables to a global logger instead of returning structured data and allowing the caller to deal with the output. Additionally there are a couple of places where errors are logged and exit is called instead of returning errors and allowing the called deal with them. We have also discovered that Pterm is not thread safe as documented in #2558 which causes more issues for unit testing.

For these reasons it has become apparent that some sort of refactoring of logging is required. A lot has happened since the initial implementation, like structured logging in standard lib. We need to define what logging is specific to the CLI and what is logging which is useful for those importing Zarf as a CLI. While it may complicate things we have to decide whether or not spinners and other "UI" elements should be used in any exported packages.

Links to any relevant code

https://github.com/defenseunicorns/zarf/blob/0c02643b9f5631a7bdd98650cc87c74901190771/src/pkg/utils/wait.go#L53 https://github.com/defenseunicorns/zarf/blob/0c02643b9f5631a7bdd98650cc87c74901190771/src/pkg/packager/common.go#L132

Additional context

We should split the work into a couple of steps to avoid creating a mega PR.

Tasks

• [x] Remove use of message fatal.
• [ ] Determine where and how spinner should be used.
• [x] Define an interface that should be used for logging.
• [ ] Replace use of Debug, Warn and Info with structure logging
• [ ] Replace use of spinner

[phillebaba]

I realize that message fatal prints the debug stack when an error occurs which exits the program. Additionally some logs will differentiate between the message and the error. The error is only written to the debug logger which the message is written to the error writer.

Before removing this logic we need to determine if this is a feature required by end users.

[catsby]

Tangential to this, I recently refactored maru-runner's log levels and handling and I see the two projects share a sort of common ancestry (I think Maru borrowed heavily from Zarf).

I would suggest we refactor Zarf log levels to match the standard libraries log/slog package, although I see that unlike maru, zarf does not always wrap log/slog but I still think it's a good convention to follow. It should provide room for the custom log levels(?) that Zarf has like Note, which currently can't be filtered out with any log level flag. I can't tell if Note() is supposed to be a log level or not though, but it's in the same package an used similarly