Motivation:

Before this change, the 'io.netty.handler.ssl.BouncyCastlePemReader'
class used by the SSL context always instantiated a new BouncyCastle
provider when one of supported providers were on the classpath. When
Netty is used in a native image created with GraalVM, the moment of
initialization matters. Providers instantiated when the native image is
built will see different classes than providers instantiated during
runtime unless every single class the BouncyCastle loads using the
reflection API is registered for a reflection. Some frameworks like
Quarkus makes sure that BouncyCastle providers are created for users and
registered with the Java Security API. However in this case, the
providers prepared by Quarkus are ignored and users are left to a
difficult task to find all required classes loaded by the BouncyCastle
for their use case and register them. This commit prefers the providers
registered against the Java Security API and fallbacks to manual class
instantiation, so that user experience improves when using native
executables.

Modifications:

I have modified
'src/main/java/io/netty/handler/ssl/BouncyCastlePemReader.java' to load
the 2 supported BouncyCastle providers (BC/BCFIPS) from the Java
Security API first and fallback to previous behavior when the providers
are not available. I didn't find any test class explicitly testing this
'BouncyCastlePemReader', therefore I added a new test class,
'src/test/java/io/netty/handler/ssl/BouncyCastlePemReaderTest.java',
that assures providers are loaded from the Java Security API, but when
not available, Netty creates a new providers if respective classes are
available on the classpath.

Result:

It will be easier to use SSL context with BouncyCastle support in native
images.

Fixes netty#14826.

Motivation:

Before this change, the 'io.netty.handler.ssl.BouncyCastlePemReader'
class used by the SSL context always instantiated a new BouncyCastle
provider when one of supported providers were on the classpath. When
Netty is used in a native image created with GraalVM, the moment of
initialization matters. Providers instantiated when the native image is
built will see different classes than providers instantiated during
runtime unless every single class the BouncyCastle loads using the
reflection API is registered for a reflection. Some frameworks like
Quarkus makes sure that BouncyCastle providers are created for users and
registered with the Java Security API. However in this case, the
providers prepared by Quarkus are ignored and users are left to a
difficult task to find all required classes loaded by the BouncyCastle
for their use case and register them. This commit prefers the providers
registered against the Java Security API and fallbacks to manual class
instantiation, so that user experience improves when using native
executables.

Modifications:

I have modified
'src/main/java/io/netty/handler/ssl/BouncyCastlePemReader.java' to load
the 2 supported BouncyCastle providers (BC/BCFIPS) from the Java
Security API first and fallback to previous behavior when the providers
are not available. I didn't find any test class explicitly testing this
'BouncyCastlePemReader', therefore I added a new test class,
'src/test/java/io/netty/handler/ssl/BouncyCastlePemReaderTest.java',
that assures providers are loaded from the Java Security API, but when
not available, Netty creates a new providers if respective classes are
available on the classpath.

Result:

It will be easier to use SSL context with BouncyCastle support in native
images.

Fixes netty#14826.

Motivation:

Before this change, the 'io.netty.handler.ssl.BouncyCastlePemReader'
class used by the SSL context always instantiated a new BouncyCastle
provider when one of supported providers were on the classpath. When
Netty is used in a native image created with GraalVM, the moment of
initialization matters. Providers instantiated when the native image is
built will see different classes than providers instantiated during
runtime unless every single class the BouncyCastle loads using the
reflection API is registered for a reflection. Some frameworks like
Quarkus makes sure that BouncyCastle providers are created for users and
registered with the Java Security API. However in this case, the
providers prepared by Quarkus are ignored and users are left to a
difficult task to find all required classes loaded by the BouncyCastle
for their use case and register them. This commit prefers the providers
registered against the Java Security API and fallbacks to manual class
instantiation, so that user experience improves when using native
executables.

Modifications:

I have modified
'src/main/java/io/netty/handler/ssl/BouncyCastlePemReader.java' to load
the 2 supported BouncyCastle providers (BC/BCFIPS) from the Java
Security API first and fallback to previous behavior when the providers
are not available. I didn't find any test class explicitly testing this
'BouncyCastlePemReader', therefore I added a new test class,
'src/test/java/io/netty/handler/ssl/BouncyCastlePemReaderTest.java',
that assures providers are loaded from the Java Security API, but when
not available, Netty creates a new providers if respective classes are
available on the classpath.

Result:

It will be easier to use SSL context with BouncyCastle support in native
images.

Fixes #14826.

Co-authored-by: Michal Vavřík <43821672+michalvavrik@users.noreply.github.com>

Motivation:

Before this change, the 'io.netty.handler.ssl.BouncyCastlePemReader'
class used by the SSL context always instantiated a new BouncyCastle
provider when one of supported providers were on the classpath. When
Netty is used in a native image created with GraalVM, the moment of
initialization matters. Providers instantiated when the native image is
built will see different classes than providers instantiated during
runtime unless every single class the BouncyCastle loads using the
reflection API is registered for a reflection. Some frameworks like
Quarkus makes sure that BouncyCastle providers are created for users and
registered with the Java Security API. However in this case, the
providers prepared by Quarkus are ignored and users are left to a
difficult task to find all required classes loaded by the BouncyCastle
for their use case and register them. This commit prefers the providers
registered against the Java Security API and fallbacks to manual class
instantiation, so that user experience improves when using native
executables.

Modifications:

I have modified
'src/main/java/io/netty/handler/ssl/BouncyCastlePemReader.java' to load
the 2 supported BouncyCastle providers (BC/BCFIPS) from the Java
Security API first and fallback to previous behavior when the providers
are not available. I didn't find any test class explicitly testing this
'BouncyCastlePemReader', therefore I added a new test class,
'src/test/java/io/netty/handler/ssl/BouncyCastlePemReaderTest.java',
that assures providers are loaded from the Java Security API, but when
not available, Netty creates a new providers if respective classes are
available on the classpath.

Result:

It will be easier to use SSL context with BouncyCastle support in native
images.

Fixes #14826.

Co-authored-by: Michal Vavřík <43821672+michalvavrik@users.noreply.github.com>

### What changes were proposed in this pull request?

This PR aims to Upgrade Netty to 4.1.119.Final.

### Why are the changes needed?

- https://github.com/netty/netty/milestone/309?closed=1
  - netty/netty#14855
  - netty/netty#14830
  - netty/netty#14816
  - netty/netty#14810

### Does this PR introduce _any_ user-facing change?

No behavior change.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #50150 from dongjoon-hyun/SPARK-51387.

Authored-by: Dongjoon Hyun <dongjoon@apache.org>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>

### What changes were proposed in this pull request?

This PR aims to Upgrade Netty to 4.1.119.Final.

### Why are the changes needed?

- https://github.com/netty/netty/milestone/309?closed=1
  - netty/netty#14855
  - netty/netty#14830
  - netty/netty#14816
  - netty/netty#14810

### Does this PR introduce _any_ user-facing change?

No behavior change.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #50150 from dongjoon-hyun/SPARK-51387.

Authored-by: Dongjoon Hyun <dongjoon@apache.org>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
(cherry picked from commit 3d949af)
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>

### What changes were proposed in this pull request?

This PR aims to Upgrade Netty to 4.1.119.Final.

### Why are the changes needed?

- https://github.com/netty/netty/milestone/309?closed=1
  - netty/netty#14855
  - netty/netty#14830
  - netty/netty#14816
  - netty/netty#14810

### Does this PR introduce _any_ user-facing change?

No behavior change.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes apache#50150 from dongjoon-hyun/SPARK-51387.

Authored-by: Dongjoon Hyun <dongjoon@apache.org>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
(cherry picked from commit 3d949af)
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>

### What changes were proposed in this pull request?

This PR aims to Upgrade Netty to 4.1.119.Final.

### Why are the changes needed?

- https://github.com/netty/netty/milestone/309?closed=1
  - netty/netty#14855
  - netty/netty#14830
  - netty/netty#14816
  - netty/netty#14810

### Does this PR introduce _any_ user-facing change?

No behavior change.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes apache#50150 from dongjoon-hyun/SPARK-51387.

Authored-by: Dongjoon Hyun <dongjoon@apache.org>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
(cherry picked from commit e84c345)
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>