build: explicitly set OpenSSL default TLS seclevel

Explicitly set the default TLS seclevel for OpenSSL. OpenSSL 3.2 changed the default TLS seclevel from 1 (default in OpenSSL 3.0 and 3.1) to 2. This causes smaller key sizes to be rejected, as well as any cipher suite that uses RC4.

Since the End-of-Life date for OpenSSL 3.0 is before the End-of-Life date for Node.js 22, we anticipate that we will need to update OpenSSL to whatever the next (as yet unannounced) LTS version of OpenSSL will be. Fixing the seclevel will minimize ecosystem disruption when that update happens.

Even with the seclevel fixed at 1, updating from OpenSSL 3.1 would still result in a change -- OpenSSL 3.1 disabled SSLv3, TLS 1.0, TLS 1.1 and DTLS 1.0 at seclevel 1.

Refs: https://docs.openssl.org/3.0/man3/SSL_CTX_set_security_level/#default-callback-behaviour Refs: https://docs.openssl.org/3.1/man3/SSL_CTX_set_security_level/#default-callback-behaviour Refs: https://docs.openssl.org/3.2/man3/SSL_CTX_set_security_level/#default-callback-behaviour Refs: https://github.com/nodejs/collaborators/discussions/202#discussioncomment-10477925

---

I'm opening this to start the conversation/see if this is something we want to do. It turns out that the change in OpenSSL 3.2 of the default seclevel from 1 to 2 is the cause of the majority of the test failures identified in https://github.com/nodejs/node/issues/53382.

If we land this, then we will become responsible for setting the default TLS seclevel in Node.js (for the binaries we build) instead of leaving it to OpenSSL. We could opt to do nothing (retain the status quo) which potentially means updating to the next LTS OpenSSL (whatever that ends up being) in Node.js 22 could break users -- we do have an explicit exception in our release policy for breaking changes for security reasons (which we could argue the OpenSSL update would be).

cc @nodejs/security-wg @nodejs/tsc @nodejs/releasers