feat: DPE-5656 log rotation new options

[paulomach]

Issue

DA124 implementation

Solution

Adds:

• new config option for log retention period
• new config option for audit log policy
• dynamic behavior for log compression and log retention period, depending on COS/logs being pushed.

Fixes #539

[sinclert-canonical]

Initial code revision, requested by Paulo.

[shayancanonical]

The log-syncing script once a COS relation is formed that waits to ensure that logs are being synced before changing the logrotation config -> the whole mechanism seems clunky. However, it seems like a sure fire way of ensuring that logs are syncing before the logrotation config is changed

Another option would be to check grep mysql.*log ${POSTIONS_FILE} in the constructor of the charm (along with a no-op if the action is already taken) -> this will be unexpected-error proof with a retry mechanism built in (when the next update-status runs). Thoughts?

[sinclert-canonical]

Looks great. Thanks for addressing all my comments!

[paulomach]

The log-syncing script once a COS relation is formed that waits to ensure that logs are being synced before changing the logrotation config -> the whole mechanism seems clunky. However, it seems like a sure fire way of ensuring that logs are syncing before the logrotation config is changed

Another option would be to check grep mysql.*log ${POSTIONS_FILE} in the constructor of the charm (along with a no-op if the action is already taken) -> this will be unexpected-error proof with a retry mechanism built in (when the next update-status runs). Thoughts?

On point. I've refactored to remove the need of the custom event, and rely on update_status instead, since this can be somewhat lazy