Update the logging properties to opt-out of the prefix events

[mickeyz07]

I would like to disable the usage of [SECURITY SUCCESS -> /com.microservices.project.handlers.SecurityHandler]

Before the usage of ESAPI the logged line was:
2024-05-03 15:14:13,912 INFO c.t.m.e.h.SecurityHandler [pool-3-thread-1] Successfully transformed security update #1

With the ESAPI the logged line becomes:
2024-05-03 15:14:13,912 INFO [pool-3-thread-1] o.o.e.l.s.Slf4JLogLevelHandlers$3: [SECURITY SUCCESS -> /com.microservices.project.handlers.SecurityHandler] Successfully transformed security update #1

As Jeremiah J. Stacey confirmed in our email conversation, following needs to be done:

• The system default should maintain the current capability if a property is not provided.
• The property should be read in as part of the LogFactory initialization process, and passed to the constructor of the LogPrefixAppender
  • This will need to be applied to all of the LogFactory implementations for consistency.
• The LogPrefixAppender will need to have a new argument to its constructor, and a new member variable too store the reference
• The LogPrefixAppender.appendTo method will need to be updated to set the boolean configurations on both the EventTypeLogSupplier and the ServerInfoSupplier
• The EventTypeLogSupplier should be expanded to provide a public setter for the boolean configuration on whether to log, and the get method will need to be updated to return an empty string when the event type is disabled.
• The ServerInfoSupplier will need an additional public setter for the classpath optional set, and the get method will need to be updated for that additional logical path.
• Tests will need to be added for the new APIs for each of the suppliers to show the behavior when both enabled and disabled match expectations.

[kwwall]

You do realize that this will also affect ESAPI's internal logging, correct? Doing so may effect the alerting on any SIEM you may be using / alerting on. The one event type where I think that might make a big difference is for the EVENT_TYPE of SECURITY_AUDIT. My original intent when I added that was to add mandatory audit trails in the logs that some audit team (like at a bank) may require. It gave them a constant to lock for regardless of what the rest of the log record might be. So, this could end up disabling that and as result, break things an potentially make them non-compliant in a regulatory way. Therefore, I think that at an absolute minimum this needs to be noted somewhere in our documentation of the property and in our the release notes. @mickeyz07 - please make a note to mention this in the ESAPI.properties file and/or in our release notes. Just wanted you to beware. Thanks.