fix: implement logging with slog and persistent config

[sabaini]

Description

This commit introduces a new logging system based on slog. It also separates backend from cli logging.

• Add new logger package with slog-based implementation
• Legacy level compatibility for API backwards compatibility
• Use new logger instead of legacy lxd-based logger
• Add CLI logger package for command-line utilities with debug/verbose flags
• Add tests

Fixes #239

Type of change

Delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• Clean code (code refactor, test updates; does not introduce functional changes)

How has this been tested?

Existing and new unit tests

Contributor checklist

Please check that you have:

• self-reviewed the code in this PR
• added code comments, particularly in less straightforward areas
• added tests to verify effectiveness of this change

[UtkarshBhatthere]

Given that the API mostly doesn't work at the moment, do you think it is worthwhile to switch the API endpoint from microceph/configs/log-level to ops/log-level. Suggesting because we do have an ops endpoint and we use it for things like replication etc.

[UtkarshBhatthere]

@sabaini i did a quick review, will do another one today.

[sabaini]

Given that the API mostly doesn't work at the moment, do you think it is worthwhile to switch the API endpoint from microceph/configs/log-level to ops/log-level. Suggesting because we do have an ops endpoint and we use it for things like replication etc.

Even if it was buggy it might have been used. I would opt for API stability unless we have very pressing need. I'd say we clean the API with the tentacle rel

[UtkarshBhatthere]

This change looks good to me, approving. We still have some lingering instances of the lxd logger which may be required to be ported to the new one. Adding this as a ticket for future will:

1. Help track that as something that needs to be done
2. Can be shared with maintenance mode maintainers as feedback.

[sabaini]

Thanks for the review @UtkarshBhatthere . As the ops_maintenance functions use LXD functionality we'll need conform to the LXD logger somewhere. Your comment got me thinking though -- handling this might be easier with an adapter that that takes our logger and adapts it to the lxd logging package. Wdyt?

[lmlg]

lgtm, good stuff