I discovered the first case when FileBase.get_path() failed, but didn't
(immediately) throw an exception. Reviewing the other instances of
JS_RepoertError() calls found several that either reported a garbage (e.g.
NULL) string value or returned JS_TRUE.

The design pattern used a little in js_socket.c probably should be used more:

	if (JS_IsExceptionPending(cx))
		return JS_FALSE;
	return JS_TRUE;

... but that's more of a refactor than I had the stomach for right now.

No functional change.

The wrong version nubmer was specified for these new properties - these
properties were added in v3.20c which is represented numerically as 32002 in
decimal.

The description of the tls_psk_id property was missing socket_prop_desc.

Now both the "regular" certificate, and PSK will be supported on
a TLS socket, and it's up to the client to check which was used.

If tls_psk is used, indicates which entry in tls_psk was used by
the remote.

If we called accept(), it's not datagram, and if you're using SCTP
and Synchronet lies to you, you can fix it yourself.

For use by broker.js which now requires a Sysop User ID and password
as the TLS PSK, and requires the system password in the MQTT password
field.

This is just the ones mentioned in the jsdocs.  I'll add more
if/when I want them. :D

This allows a server that's being terminated to stop the port-bind delay/retry
loops and terminate more quickly in cases of port binding failures.

... using uncrustify mod_paren_on_return config

White-space changes only, exception being the rare insertion of NL before
closing brace (couldn't find the option to disable that behavior).

I excluded some header files (e.g. sbbs.h) since uncrustify seemed to be doing
more harm than good there. I might just end up applying different set of rules
to .h files.

On JS TLS sockets, sends over 16384 bytes would be truncated to
the next multiple of 8192 higher than half the buffer length.

This was triggered because we send chunks of 8192 bytes at a time,
and decrement the length each time through the loop.  We return
"success" when the total sent so far is higher than the length
remaining.

Fixes bug reported in #Synchronet by Accession.

Make js_socket_sendfilesocket() suck a lot less.
This commit brought to you with limited rants by Synchronet 3.20b

"Warning: Your BBS may become habit forming."

You could run Synchronet or you could settle for mediocrity.

Once in a great while, there comes BBS software that really makes waves.
Get out your surfboard.

The best BBS software is the most expensive BBS software.
NOT!

If you had three wishes, you could toss the other two.

They couldn't top Synchronet.  So we did.

Accept the inevitable, switch to Synchronet

This was a regression: Socket.recvline() used to not care what the timeout
duration was so long as there were bytes to receive.

Also, remove the ".0" from timeout values in documented mehtods that don't
(any longer) accept floating point timeout durations. We used to support
fractional seconds for some of these methods, and that was implied by using
the floating point default values, but that's no longer the case. poll()
still accepts a floating point timeout.

As was discovered as part of investigation into issue #769, a JavaScript
could crash SBBS (cause a segfault) due to a NULL pointer dereference when
the script passes 'null' to native JS functions where an object is expected.

The issue raised was with console.gotoxy(), but it turns out that *many*
Synchronet native JS functions would call JSVAL_TO_OBJECT() and then, without
checking for NULL/nullptr, pass its return value to JS api functions such as
JS_GetPrivate, JS_GetProperty, JS_GetClass, JS_ObjectIsFunction,
JS_IsArrayObject, JS_GetArrayLength, JS_DefineProperty, JS_Enumerate, etc.
All of these JS API functions dereference the passed object pointer without
NULL/nullptr checking.

The fix here is to either call JSVAL_IS_NULL() or JSVAL_NULL_OR_VOID() and
if true, not call JSVAL_TO_OBJECT() and/or check the return value for the NULL
value before using as an argument to any other JS API functions.

As Nelgin pointed out, a Socket.connect() failure for reasons of address/host
lookup failure would report a stale/nonsense Socket.error/error_str value.

This change required us to query/store the socket API/getaddrinfo error string
at the time of failure (for the Socket.error_str property value) rather than
converting from number to string at the time the property is read.

This does mean that sometimes Socket.error is a errno value and sometimes its
a getaddrinfo (EAI_*) error value. Since the EAI_* values are negative, it
should be obvious which is which.

TLS 1.2.  For static services and JS sockets, add a new tls_minver
socket property which can be set to use a lower minver (down to the
wildly insecure TLS 1.0).

TLS 1.0 and 1.1 have been not reccomended since 2015, and deprecated
since 2021.

Still using BOOL where we need Win32 API compatibility.
Using JSBool instead of BOOL or bool where it matters.
Changed most relevant TRUE/FALSE to true/false too (though it's not as critical).

You shouldn't need to #include <stdbool.h> anywhere now - gen_defs.h should do that automatically/correctly based on the language/version/tool. In C23, stdbool.h isn't even needed for bool/true/false definitions (they're keywords), so we don't bother including stdbool.h in that case.
Microsoft didn't define __STDC_VERSION__ in their older tool chains (even though they were C99 compatible and had stdbool.h), so we use a _MSC_VER check to know that there's a stdbool.h we should use in that case.

For other/old compilers (e.g. Borland C) we #define bool/true/false following the pattern of stdbool.h (doesn't use a typedef).

I didn't convert UIFC yet.

This addresses issue #698

TLS clients don't (currently) add a certificate, so there's no need
to delete it.

Use cryptDestroySession() instead.

Should calm the clang warnings reported by Deuce:

e.g.
passing 'char *[18]' to parameter of type 'const char **' discards qualifiers in nested pointer types

The JS objects will still log to the terminal server (regardless of which server created/used the objects) however - so that's still a TODO.
Change do_cryptInit() to return bool, since it does.
Log detailed error if pthread_once() call fails.
Lowered-severity (to DEBUG) the log messages related to TLS private key and cert creation and destruction.

FIrst commit from within MSVS, so this might look weird.

Private key objects in cryptlib are not copied into sessions when
they're added, only the refcount is incremented.  These objects
contain a bignum context, which therefore ends up shared across all
instances of the private key.  Unfortunately, the locking is on the
session context, not the private key objects, so shared bignum contexts
can cause memory corruption.

Further, even if the locking issue was fixed, the performance handbrake
would still exists... activating sessions that use the same private key
would be serialized, with the results we've been seeing lately.

With this, each session gets a unique private key, which is loaded
from the file.  When a session is finished with the key, it is cached
in a list with an epoch, so when the date on the key file changes, old
private keys will be eliminated.

While this solves a lot of issues, logging of certificate generation
and loading issues has regressed to the point where it's effectively
not done at all. Logging was previously passed back to the caller,
but given the much longer call chain to get to where a cert is created,
the extra parameters was just too much. Something better should be
done here at some point.

Also, expand the lock in websrvr to the correct scope.

We'll hold a reader lock under the session is established, which
should prevent blocking other threads unless something is beating
on get_ssl_cert() (which would be a different bug).

This still needs to be figured out, but at least this should fix
the immediate issue.

Holding the lock around session establishment should not be needed,
but we need to protect tls_certificate read and usage.  Since we
don't have rwlocks in xpdev (yet?), hack together a crappy rwlock
that does what we need.

error: expected ‘)’ before string constant

Harumph.