tls: avoid throw in onerror for bad TLSSocket obj

TLSWrap.onerror has a helpful debug() call built in to it. However in
case of a malformed TLSSocket object, where the `_tlsOptions` value is
an unexpected `undefined`, accessing `_tlsOptions.isServer` causes
a TypeError to be thrown.

This commit ensures that the debug() call properly logs the state as
'unknown', instead of the two 'server' and 'client' choices previously
available. Additionally, onerror branching is adjusted to allow such
`undefined` options object, by use of optional chaining.

Other methods are not being adjusted, as such a case of `undefined`
options is not viable during regular processing of the TLSSocket.

Fixes: #41501

Author: sigv

lib/_tls_wrap.js

@@ -408,8 +408,10 @@ function onocspresponse(resp) {
 function onerror(err) {
   const owner = this[owner_symbol];
   debug('%s onerror %s had? %j',
-        owner._tlsOptions.isServer ? 'server' : 'client', err,
-        owner._hadError);
+        (typeof owner._tlsOptions === 'object' && owner._tlsOptions !== null) ?
+            owner._tlsOptions.isServer ? 'server' : 'client' :
+            'unknown',
+        err, owner._hadError);
 
   if (owner._hadError)
     return;
@@ -421,7 +423,7 @@ function onerror(err) {
     // When handshake fails control is not yet released,
     // so self._tlsError will return null instead of actual error
     owner.destroy(err);
-  } else if (owner._tlsOptions.isServer &&
+  } else if (owner._tlsOptions?.isServer &&
              owner._rejectUnauthorized &&
              RegExpPrototypeTest(/peer did not return a certificate/,
                                  err.message)) {