feat: centralize configuration logging

[mattp-swirldslabs]

Description:

• Centralized the logging of configuration properties in the ConfigurationLoggingImpl class
• Added @Loggable annotation to allow developers to indicate a field can be logged normally
• Fields without @Loggable are safe by default. The property name will be displayed but the value will always be the same "*****" e.g. my.property=*****
• Converted Config records using "NOOP" string to an enum
• Replaced VerificationConfig enabled with an enum
• Removed log output from other Config records
• Added a commented out property in logging.properties showing how to switch OFF the output

Related issue(s):

Fixes #471
Fixes #474

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[AlfredoG87]

LGTM, nice work.

[AlfredoG87]

@mattp-swirldslabs, this should be part of Milestone 0.4.0 already moved it.

[ata-nas]

Good job @mattp-swirldslabs! the logging looks really good!
I do think however that some changes are due in the sanity test and in the way we handle config classes we do not own. Also some optional nits and cleanup suggested.

[AlfredoG87]

LGTM.

@mattp-swirldslabs @ata-nas @jsync-swirlds let's try to capture nits, improvements and suggestions on a follow-up ticket, and move forward with this, we cannot afford to spend any more time on some of the nits am reading here. This is way better than what we used to have (no logging or visibility of configuration loaded by the system).

My suggestions is to merge as currently is this PR.

[ata-nas]

LGTM.

@mattp-swirldslabs @ata-nas @jsync-swirlds let's try to capture nits, improvements and suggestions on a follow-up ticket, and move forward with this, we cannot afford to spend any more time on some of the nits am reading here. This is way better than what we used to have (no logging or visibility of configuration loaded by the system).

My suggestions is to merge as currently is this PR.

I would agree to that, @mattp-swirldslabs please kindly capture/acknowledge nits/considerations which came up above and for me the conversations would be considered resolved (which are not even final, could be or not be implemented in the long run, mind you there are already planned changes to the configuration with the query endpoint) and we can proceed.

P.S. @AlfredoG87 I agree on the time sensitivity, I am not trying to block. just some considerations come and I want to acknowledge them. My ask is not to resolve everything now, just to capture what comes to mind.

[ata-nas]

🔥