crypto: add crypto::GetSSLCtx API for addon access to OpenSSL contexts

[pimterry]

Once upon a time (#20237) we attempted to remove the secureContext.context._external field which exposes OpenSSL contexts. This was later reverted (#21711) because it turns out there are external native addons which do want to integrate with Node's OpenSSL, and were using this JS API as it's currently the only way to do so.

At the time, @sam-github said:

maybe there is some way to have a pure C++ API, perhaps node::crypto::GetSecureContextFromHandle(), that would allow C++ addons to get the SecureContext? This would make more sense to me, given that the SecureContext can only be used with the SSL_ APIs by C++ code, only C++ needs to get it. This would still have the positive effect of removing the context from the js API.

I think this makes a lot of sense. I'm in the process of building a native addon myself that needs access to OpenSSL contexts (user-space solution for #41112). I'd like to do this properly, without having to awkwardly hook onto internals like this.

This PR does that: creating a new node::crypto::GetSSLCtx native API, so C++ addons can access the OpenSSL context directly. With this in place, we could potentially drop _external entirely from the JS API (and maybe even .context) in some future major bump. Naming is intended to match the SSL_CTX type and OpenSSL SSL_CTX_... APIs etc, but open to bikeshedding that further.

This API itself should be easy to keep stable as OpenSSL changes, but obviously SSL_CTX won't be stable as it has APIs that will change as we upgrade OpenSSL versions etc. I think that's fine, there's clearly no real avoiding that and addons using this will have to be able to deal with OpenSSL changes like this appropriately. Reasonable given that it's a native-only API imo.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto
• @nodejs/gyp

[codecov]

Codecov Report

❌ Patch coverage is 88.23529% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.66%. Comparing base (65b521f) to head (e378906).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
src/crypto/crypto_context.cc	88.23%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62254      +/-   ##
==========================================
- Coverage   89.66%   89.66%   -0.01%     
==========================================
  Files         676      676              
  Lines      206500   206572      +72     
  Branches    39539    39555      +16     
==========================================
+ Hits       185168   185231      +63     
+ Misses      13463    13459       -4     
- Partials     7869     7882      +13     

Files with missing lines	Coverage Δ
src/node.h	92.30% <ø> (ø)
src/crypto/crypto_context.cc	71.98% <88.23%> (+0.47%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[addaleax]

You probably need OpenSSL-available guards here as well, but I think CI will tell whether that's the case

[pimterry]

I think it probably doesn't, and the other openssl addons test don't. I think this is covered by the binding build config.

[addaleax]

This should be in a try/catch, right?

[pimterry]

Good point - done. Just swallowing the error here, which is a bit debatable, but this API currently just consistently returns null for other cases where no context is available and that seems reasonable for the native addon use case, so I'm inclined to keep it simple.