[lihuiba]

What

net/security-context/test/test_cert_utils.h hands the result of
X509_get_subject_name() to X509_NAME_add_entry_by_txt() and
X509_set_issuer_name(), which take a mutable X509_NAME*. The getter's return
qualifier depends on the OpenSSL headers in use: 1.1.1 returns X509_NAME*,
newer ones return const X509_NAME*. With the newer headers the five call sites
fail to compile:

test_cert_utils.h:35:5: error: no matching function for call to 'X509_NAME_add_entry_by_txt'
... candidate function not viable: 1st argument ('const X509_NAME *') would lose const qualifier

This is what broke the macOS arm CI image (whose homebrew OpenSSL is newer) while
the intel image, on 1.1.1, stayed green -- same source, two header versions.

How

One helper takes the writable view back, and the five sites use it:

inline X509_NAME* test_subject_name(X509* cert) {
    return const_cast<X509_NAME*>(X509_get_subject_name(cert));
}

No version macro: on the old signature const_cast removes no qualifier and is a
no-op, so the same text compiles against both. The cast is sound because these
certificates are built here and are writable.

Verification

• -fsyntax-only on net/http/test/client_function_test.cpp with OpenSSL 3.6.3
  headers: clean.
• The same helper text compiled against both getter signatures (mutable and
  const) in one TU: compiles in both directions.
• CI: the macOS arm job is the witness for the const signature; Linux and the
  macOS intel job cover the mutable one.