Motivation:

Historically, BoringSSL lacked a built-in method to select between RSA
and ECDSA certificates. The selection process, especially at TLS 1.2, is
quite complex, as detailed in [this
link](https://boringssl.googlesource.com/boringssl/+/5a3faaa2d50b2540c6973531841723f633f388cd/ssl/test/runner/runner.go#19669).
TLS 1.3 simplifies this process significantly. Additionally, within
ECDSA, there are different curves to consider, and future developments
will introduce post-quantum key types. The SSL Credential API was
introduced to BoringSSL to address this and a variety of other
certificate negotiation decisions, such as:

Different kinds of credentials ([delegate
credentials](https://www.rfc-editor.org/rfc/rfc9345.html), [raw public
keys](https://www.rfc-editor.org/rfc/rfc7250.html), [external
PSKs](https://www.rfc-editor.org/rfc/rfc9258.html), and more [future
innovations](https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html).
[Negotiation for trust
anchors](https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md)
to aid in PQ transitions and PKI agility.

Modification:

Introduce high level APIs leveraging the most useful bindings introduced
in netty/netty-tcnative#935

```java
OpenSslCredential credential = OpenSslCredentialBuilder.newX509(privateKey, chain)
    .trustAnchorId(anchorId)
    .mustMatchIssuer(true)
    .build();
```

Result:

There are two main immediate use cases to this API
First, it is now possible to delegate all the complexity of EC/RSA
serving to BoringSSL.
```java
OpenSslCredential ecdsaCred = buildEcdsaCredential();

SslContext ctx = SslContextBuilder.forServer(rsaKey, rsaCert)
    .sslProvider(SslProvider.OPENSSL_REFCNT)
    .credential(ecdsaCred)
    .build();
```
This mechanism will also be useful to allow clients to negotiate trust
anchors via https://github.com/tlswg/tls-trust-anchor-ids. For example,
a modern client may request for a more efficient or more secure chain
while legacy clients can still receive the less secure / less efficient
fallback cert.


depends on netty/netty-tcnative#949

---------

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Co-authored-by: Chris Vest <christianvest_hansen@apple.com>

Motivation:

Historically, BoringSSL lacked a built-in method to select between RSA
and ECDSA certificates. The selection process, especially at TLS 1.2, is
quite complex, as detailed in [this
link](https://boringssl.googlesource.com/boringssl/+/5a3faaa2d50b2540c6973531841723f633f388cd/ssl/test/runner/runner.go#19669).
TLS 1.3 simplifies this process significantly. Additionally, within
ECDSA, there are different curves to consider, and future developments
will introduce post-quantum key types. The SSL Credential API was
introduced to BoringSSL to address this and a variety of other
certificate negotiation decisions, such as:

Different kinds of credentials ([delegate
credentials](https://www.rfc-editor.org/rfc/rfc9345.html), [raw public
keys](https://www.rfc-editor.org/rfc/rfc7250.html), [external
PSKs](https://www.rfc-editor.org/rfc/rfc9258.html), and more [future
innovations](https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html).
[Negotiation for trust
anchors](https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md)
to aid in PQ transitions and PKI agility.

Modification:

Introduce high level APIs leveraging the most useful bindings introduced
in netty/netty-tcnative#935

```java
OpenSslCredential credential = OpenSslCredentialBuilder.newX509(privateKey, chain)
    .trustAnchorId(anchorId)
    .mustMatchIssuer(true)
    .build();
```

Result:

There are two main immediate use cases to this API
First, it is now possible to delegate all the complexity of EC/RSA
serving to BoringSSL.
```java
OpenSslCredential ecdsaCred = buildEcdsaCredential();

SslContext ctx = SslContextBuilder.forServer(rsaKey, rsaCert)
    .sslProvider(SslProvider.OPENSSL_REFCNT)
    .credential(ecdsaCred)
    .build();
```
This mechanism will also be useful to allow clients to negotiate trust
anchors via https://github.com/tlswg/tls-trust-anchor-ids. For example,
a modern client may request for a more efficient or more secure chain
while legacy clients can still receive the less secure / less efficient
fallback cert.

depends on netty/netty-tcnative#949

---------

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Co-authored-by: Chris Vest <christianvest_hansen@apple.com>
(cherry picked from commit a40fb71)

Forward port of #15919 to 5.0
Cherry-picked commit: a40fb71

---
Motivation:

Historically, BoringSSL lacked a built-in method to select between RSA
and ECDSA certificates. The selection process, especially at TLS 1.2, is
quite complex, as detailed in [this
link](https://boringssl.googlesource.com/boringssl/+/5a3faaa2d50b2540c6973531841723f633f388cd/ssl/test/runner/runner.go#19669).
TLS 1.3 simplifies this process significantly. Additionally, within
ECDSA, there are different curves to consider, and future developments
will introduce post-quantum key types. The SSL Credential API was
introduced to BoringSSL to address this and a variety of other
certificate negotiation decisions, such as:

Different kinds of credentials ([delegate
credentials](https://www.rfc-editor.org/rfc/rfc9345.html), [raw public
keys](https://www.rfc-editor.org/rfc/rfc7250.html), [external
PSKs](https://www.rfc-editor.org/rfc/rfc9258.html), and more [future
innovations](https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html).
[Negotiation for trust
anchors](https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md)
to aid in PQ transitions and PKI agility.

Modification:

Introduce high level APIs leveraging the most useful bindings introduced
in netty/netty-tcnative#935

```java
OpenSslCredential credential = OpenSslCredentialBuilder.newX509(privateKey, chain)
    .trustAnchorId(anchorId)
    .mustMatchIssuer(true)
    .build();
```

Result:

There are two main immediate use cases to this API
First, it is now possible to delegate all the complexity of EC/RSA
serving to BoringSSL.
```java
OpenSslCredential ecdsaCred = buildEcdsaCredential();

SslContext ctx = SslContextBuilder.forServer(rsaKey, rsaCert)
    .sslProvider(SslProvider.OPENSSL_REFCNT)
    .credential(ecdsaCred)
    .build();
```
This mechanism will also be useful to allow clients to negotiate trust
anchors via https://github.com/tlswg/tls-trust-anchor-ids. For example,
a modern client may request for a more efficient or more secure chain
while legacy clients can still receive the less secure / less efficient
fallback cert.


depends on netty/netty-tcnative#949

Co-authored-by: Jared Crawford <jmcrawford45@gmail.com>
Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Co-authored-by: Chris Vest <christianvest_hansen@apple.com>

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

This PR aims to upgrade `netty-tcnative` to 2.0.75.Final.

### Why are the changes needed?

To bring the latest bug fixes.
- netty/netty-tcnative@netty-tcnative-parent-2.0.74.Final...netty-tcnative-parent-2.0.75.Final
  - netty/netty-tcnative#948
  - netty/netty-tcnative#949
  - netty/netty-tcnative#950

### 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 #54830 from dongjoon-hyun/SPARK-56009.

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