[sharanggupta]

Fixes #3155.

AbstractConfiguration.addLoggerAppender, addLoggerFilter and setLoggerAdditive (the implementation behind core.Logger#addAppender, #addFilter and #setAdditive) ignored the result of their putIfAbsent calls:

• addLoggerAppender: when a different appender instance was already registered under the same name, the new instance was not registered but was still attached to the LoggerConfig, so the logger wrote to an appender the configuration never started or stopped while getAppender(name) returned another one. The registered instance is now attached instead (first wins, as addAppender already behaves), with a status-logger warning.
• All three: the result of loggerConfigs.putIfAbsent(loggerName, nlc) is respected; when a config already exists the change is applied to it instead of re-wiring the parents and updating the loggers again. Under the method lock and the exact-name lookup that precedes it this branch is defensive, so it has no test of its own.
• addLoggerFilter and setLoggerAdditive now ignore null arguments like addLoggerAppender does, instead of throwing NullPointerException (side note 1 in the issue).

Tests, one per method in AbstractConfigurationTest: the duplicate-name appender case; the filter case (null arguments ignored, exactly one LoggerConfig created with the right parent, both filters applied); the additive case (null logger ignored, one config created, additivity reflected by the logger). All three fail before the change and pass after. Changelog entry for 2.x included.

Checklist

• Based on 2.x
• ./mvnw verify on log4j-core / log4j-core-test with AbstractConfigurationTest succeeds (spotless applied)
• Changelog entry in src/changelog/.2.x.x
• Tests are provided

[sharanggupta]

Folded into #4419 as a second commit (941a6a7), as asked on #3155. Closing this one.