If a relative path to the ctrl directory is specified on the command-line
or in the SBBSCTRL environment variable, the loading of ctrl/*.ini would
fail after the changing of the working directory.

We should probably get replace all use of FULLPATH with _fullpath someday,
but for now, I just went with majority-rule.

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

e.g. User.downlaoded_file() will now publish to the appropriate MQTT topic and changes to system.node_list[] will get published to MQTT.

Where ever we assign the realloc() result to the same pointer we pass, use this new function instead to eliminate the cppcheck error reported by Nelgin:
Common realloc mistake: 'p' nulled but not freed upon failure  [memleakOnRealloc]

This isn't going to actually solve any memory leaks, it's just good practice for critical error (e.g. no memory error) handling.

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.

The '-l' (loop) option would cause the JS runtime to be destroyed and
recreated for each new execution of the script, which resulted in memory
leaks in Windows builds (see issue #672 for details). So instead, just
use a single JS runtime here when the -l option is used to prevent that
from happening, though truth be told, that's likely not a normal/common
occurrence. Other apparent JS-related memory leaks (e.g. in the web
server) appear to be of a common concern.

Likely upgrading to a modern libmozjs would also fix this issue, but
we're far short of being able to do that right now.

A "prepped" means directory means a relative path from the configuration files
(or default settings) has been converted to a full/absolute path with proper
slashes for the platform (i.e. backslashes instead of forward-slashes on
Windows).

JSexec doesn't require that the new v3.20 ctrl/*.ini files exist to run; this
was necessary to be able to run 'jsexec update -> upgrade_to_v320.js' which
does the ctrl/*.cnf to .ini file conversion (egg not required to build
chicken). When JSexec failed to load ctrl/msgs.ini
(e.g. "!ERROR loading configuration files: 2 (No such file or directory)
opening /sbbs/ctrl\msgs.ini"), it would continue to run, but not "prep" any
of the "path" settings (e.g. exec_dir).

The first run of 'jsexec update.js' would fail to run upgrade_to_v320.exe
(which does the v3.20 user base conversion) and a bunch of other (but not as
important) update steps because Windows couldn't execute "../exec/*".

Multiple errors would be displayed in this case, but the most important (as
reported by Ree in #synchronet of irc.synchro.net) was:
  '..' is not recognized as an internal or external command

right after the status output:
  No v3.20 user base found, running ../exec/upgrade_to_v320

Notice the "../exec/" prefix, which is not support by Windows when specifying
a file path to execute.

A second run of 'jsexec update' would work fine because the new v3.20 .ini
files would be successfully created after the first run (though the user base
was not).

This is likely the same issue that MRO reported recently when upgrading a
Windows SBBS v3.19 install to v3.20 and not having the user base upgraded
the first time.

Eliminates a SANITIZE build error

This macro hasn't done anything meaningful since we stopped using really old
versions of Borland compilers (and std libraries) where strerror() returned a
string terminated with a line-feed (\n) character.

A bunch of possible (but often, not really) use of undefined values.
Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets).

Other than some added diagnostics upon some of these unexpected syscall
failures, there should be no change in behavior from this commit.

Mainly capitalization, but some typos and added details. 

It seems Linux has deprecated siginterrupt(), and they've been
aggressive about removing deprecated C functions lately.

Now, if the BOOL argument value is FALSE, then the .ini file is opened read-only (and thus only read permissions are needed, resolving issue #455).

If the BOOL argument value is TRUE, create-if-not-exist is implied. There are no use cases where we would want to open an .ini file for writing only if it already existed.

JSexec needs to be able to run upgrade_to_v320.js without main.ini
already existing, but we need some cfg values (e.g. exec_dir) to
find/execute scripts.

Added -R option to jsexec to (re)require successful config file
loaded, if/when needed by something.

Solves problem of status output lines being interleved with console
output (e.g. from print()) after executing a script.

CID 174223
CID 174227
CID 174461
CID 174519
CID 229602
CID 319040
CID 319137
CID 319159

This appears to work and the event handler *should* work on other
event types already.

Note, this is *nix-only due to the use of poll().  select() will
need to be used for Windows to keep XP compatability.

This option fixes the fact that the following two lines sometimes
place the variables in different scopes at the top-level of included
scripts:
var x = 1;
y = 2;

I plan to use this to experiment on if this is what's causing much
of the remaining scope chain weirdness... it certain explains some
things we've been seeing (and possibly even things like the METHODJIT
issues DigitalMan saw yesterday).

Enabling in sbbs/jsexec is a much bigger lift, but this change may
end up being all upside... the docs have suggested this option always
be set since it was originally introduced, and now that I understand
scopes better, it's pretty clear why that is.

METHODJIT (JägerMonkey) is doing weird stuff with xtrn_sec.js when
enabled, so don't introduce that noise.

This should fix the recent JSDoor build issue introduced.

JavaScriptOptions bit-field can be set in sbbs.ini and jsexec.ini to over-ride the default JS compiler options which have been changed from 0 to (options previously only used by JSDoor):
JIT | METHODJIT | COMPILE_N_GO | PROFILING

* JIT - TraceMonkey
* METHODJIT - JägerMonkey
* COMPILE_N_GO - compile-time scope chain resolution of consts
* PROFILING - Choose between TraceMonkey and JägerMonkey at compile-time based on profiling results

Other options available but not enabled by default:
* STRICT - warn on debious practice (i.e. similar to "use strict")
* WERROR - convert warnings to errors
* VAROBJFIX -  use last object on scope chain as the ECMA 'variables object'
* RELIMIT - Throw exception on any regular expression which backtracks more than n^3 times, where n is length of the input string
* ANONFUNFIX - Disallow function () {} in statement context per ECMA-262 Edition 3.
* METHODJIT_ALWAYS - Always whole-method JIT, don't tune at run-time.

Also:
- Fixed JS warning string formatting (missing space separator).
- Removed an extraneous new-line in lprintf() call in mailsrvr.
- Added basic assertEq() global method to jsexec, required when running SpiderMonkey test scripts.

Mostly in error-paths.

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

Don't return an error if the node#/node.cnf file can't be opened for all uses of load_cfg() except from the terminal server. This fixes #214 for Tracker1

Also change the wording of the -D option to be more descriptive.

Also, it's not technically an option, so remove from the option list.

At Tracker1's request/suggestion.

jsexec -Itrue
...
Result (boolean): true

More elaborate expressions can be evaluated and white-space included by quoting the "-I expression".

Also, send all cmd-line usage errors to stderr and syntax help to stdout, always (Deuce's request).