Add slf4j-nop in order to prevent startup warnings

[pgomulka]

currently when Elasticsearch starts up there are warnings on the console

SLF4J: No SLF4J providers were found. SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details. SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier. SLF4J: Ignoring binding found at [jar:file:/Users/chegar/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-slf4j-impl/2.19.0/1a0c9615ba9fd5b96db8c1136afbef4394286e93/log4j-slf4j-impl-2.19.0.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation. 

this is emitted twice
1 - when repository-azure module is loaded
2 - when transport-netty-4 module is loaded (transitively via xpack-security)

This commits adds a slf4j-nop to fix that warning

however this is unclear to my why they started in the first place.
might be related to #93714
and #93878

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[pgomulka]

netty is using slf4j-api as an optional dependency. That dependency is being 'injected' via xpack-security dependency (how??)

stacktrace when slf4j is being used

bind:178, LoggerFactory (org.slf4j) performInitialization:170, LoggerFactory (org.slf4j) getProvider:455, LoggerFactory (org.slf4j) getILoggerFactory:441, LoggerFactory (org.slf4j) <init>:42, Slf4JLoggerFactory (io.netty.util.internal.logging) <clinit>:63, Slf4JLoggerFactory$NopInstanceHolder (io.netty.util.internal.logging) getInstanceWithNopCheck:59, Slf4JLoggerFactory (io.netty.util.internal.logging) useSlf4JLoggerFactory:62, InternalLoggerFactory (io.netty.util.internal.logging) newDefaultFactory:42, InternalLoggerFactory (io.netty.util.internal.logging) getDefaultFactory:111, InternalLoggerFactory (io.netty.util.internal.logging) getInstance:134, InternalLoggerFactory (io.netty.util.internal.logging) getInstance:127, InternalLoggerFactory (io.netty.util.internal.logging) <clinit>:81, PlatformDependent (io.netty.util.internal) <init>:34, ConstantPool (io.netty.util) <init>:36, ChannelOption$1 (io.netty.channel) <clinit>:36, ChannelOption (io.netty.channel) <clinit>:92, Netty4Transport (org.elasticsearch.transport.netty4) lambda$getTransports$27:1571, Security (org.elasticsearch.xpack.security) get:-1, Security$$Lambda$4841/0x0000000801c14b08 (org.elasticsearch.xpack.security) <init>:815, Node (org.elasticsearch.node) <init>:327, Node (org.elasticsearch.node) <init>:216, Elasticsearch$2 (org.elasticsearch.bootstrap) initPhase3:216, Elasticsearch (org.elasticsearch.bootstrap) main:67, Elasticsearch (org.elasticsearch.bootstrap) 

[pgomulka]

That dependency is being 'injected' via xpack-security dependency (how??)

if this is the case then x-pack-securitys api "org.apache.logging.log4j:log4j-slf4j-impl:${versions.log4j}" dependency can also influence other modules? Like ingest-attachmenet which is explicitly trying not to use it

[rjernst]

x-pack-security actually contains a second copy of transport-netty4, which it builds the security http/s implementations on top of. Although transport-netty4 still exists as a module, it is never loaded because x-pack-security overrides the transport implementation settings. So the version of transport-netty4 that needs fixing is just that in x-pack-security, where the nop dep can be a runtime dependency.

[elasticsearchmachine]

Hi @pgomulka, I've created a changelog YAML for you.

[ChrisHegarty]

LGTM