Update to commit 85a2de04 (2 years ago).

FSC-74 specifies:
"The conference name shall be no more than 60 characters in length."

SCFG was limiting sub and dir area-tags to 40 chars and SBBSecho was limiting
area tags to 50 chars in length.

FSC-74 isn't a standard, but lacking this detail in FTS-4 and considering it
comes from the same authoritative source (the Conference Mail System User
Manual), I think it's the best source of truth we have.

Also, since we're no longer using .cnf files, we don't need different max
area-tag lengths between SBBSecho and SCFG structs - they all now use the same
macro: FIDO_AREATAG_LEN

We're just using it to "fix" the case, if the file indeed exists.

If client socket is connected, wait up to the specified timeout period (in ms)
for the output buffer to be emptied.

This is much preferred over blindly calling mswait() after sending some data
(e.g. a file) and possibly waiting much longer than necessary.

Since the Terminal Server is a single thread, let's not block for long
periods of time trying to send bytes to a client (e.g. send the badip.msg
file contents to a client with a blocked IP address), effectively DoSing the
terminal server.

This should address the problem reported via IRC:
<theviper4> │Apr  9 15:38:11 viper-bbs synchronet: term Terminal Server timeout(outcom) 0000 0000
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 110 sending on socket 39
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 32 sending on socket 39
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 32 sending on socket 39
<theviper4> │Apr  9 15:38:36 viper-bbs synchronet: term 0039 Telnet !CLIENT BLOCKED in ip.can: 117.95.153.33

Also, make the outcom timeout error message more helpful (e.g. include the
sock descriptor of the client) and don't use the old rioctl() function
here any more.

yes, this is a Y2K38 (or Y2106) issue, but we should have that worked out
when upgrading to the next libmozjs.

Need something like NUMBER_TO_JSVAL() and equivalent LAZY_NUMBER macro that
can deal with >32-bit ints correctly (or just always convert to double?).

... while the mods/*.bin command shell filenames could be any-case!

Only impacted non-Windows systems (UNIX file systems are case-sensitive).

Discovered while making this tutorial video: https://youtu.be/HlwQ0uX4S04

This is the time_t (seconds since Unix epoch, Jan-1-1970 UTC) date/time of the
current (most recent) Git commit used to build the running binary.

If a JS developer wants to check if a build is recent-enough to include some
change, this is the property they should use to check (with >= comparison).

This solves the problem of exit() values (e.g. non-zero return codes) not
getting propagated to callers when nest-called (e.g. via bbs.exec()).

I think it was kk4qbn that pointed this out via IRC: an exit(1) call from
prextrn.js did not stop the external program from running (as it should, for
any non-zero exit code). This only happened when the prextrn.js called another
JS script (e.g. via bbs.exec() or as was the case here, indirectly via "EXEC"
@-code in the YesNoBar text.dat string (which executed yesnobar.js). This
nested JS script invocation via sbbs_t::js_execfile() would clobber the stored
js.scope property value (where the "exit_code" property is written).

Script invoked in their own context (e.g. via js.exec()) wouldn't have this
issue in the first place.

A QWKnet tagline usually contains CP437 character 254 and if/when appended to
a message during export, would "convert" the message to CP437 thus making the
"ASCII" charset advertisement incorrect.

If a FIDO CHARSET value was already specified (e.g. in HEADERS.DAT), that
value will (still) not be overridden. So the *original* import via QWK (before
it gets exported to a QWKnet) is where this change will take effect.

Fix for issue #741

When invoking a nested JS script, these properties of the "js" object would
be overwritten and not restored, as discovered/reported by Nightfox when his
trivial game script would indirectly execute yesnobar.js, his subsequent use
of js.exec_dir would point to the wrong location (the "exec" directory, parent
of yesnobar.js, and not the direcctory where his game script was located).
The exec_path and exec_file properties had the same problem as demonstrated
by a simple test.js placed in (and executed from) a directory other than the
"exec" dir:
	function f() {
        print("js.exec_path = " + js.exec_path);
        print("js.exec_dir = " + js.exec_dir);
        print("Js.exec_file = " + js.exec_file);
	}
	f();
	console.yesno("test");
	f();

This would only trigger the problem when executed from the BBS and whebn the
YesNoQuestion text.dat string invokes the "yesnobar" module via EXEC @-code and
yesnobar.js exists (in exec or mods dir), superceding yesnobar.bin which does
not trigger this issue (not a JavaScript mod).

Hopefully fixes issue where certificate file is left open and so
can't be deleted.

The big remaining issue is defining *_EXPORTS where needed, which
looks rough from a quick glance.

There's only one toggle left (Leave node file open) and not very many advanced
options.

Unfortuantely, can't easily do the cool left-right cycle through nodes since
each node file has to be saved/loaded, but still, easier to visualize any
differences between node configs with all the settings on one menu.

From SCFG->Nodes ... Toggle Options to SCFG->System->Toggle Options

And from a bit flag in node_misc to its own bool member of scfg_t.

The way this option worked was, if enabled (and it was off by default), bit 7
of all character input *before* successful logon would be stripped and bit 7
from all character input of terminals configured as US-ASCII (only) would be
stripped after logon.

Instead, always strip bit 7 (the 8th bit) of each input character from US-ASCII
(only) terminals. Other detected/configured terminals (CP437, UTF-8, PETSCII)
won't have bit 7 stripped (ever) since that's likely not a necessary or nice
thing to do. There's now no different handling of pre/post logon in this
regard.

If there's a need to strip parity bits from character input from client
terminals that support CP437, UTF-8, or PETSCII, then we'll re-add this feature
in but it shouldn't be a per-node setting in that case.

4-bytes is how bit a 32-bit pointer is.

Yeah, it's getting about that time...

Passing an unparseable integer to console.editfile() could leak heap memory

A couple of error paths in expand_atcodes() method could leak heap memory.

This should resolve CID 487088: Unchecked return value from library
as well as add some more instrumentation upon unexpected failures removing
files.

Consider: do some callers of this function need to know the success status
(return bool)? That then starts to get into the some callers check and some
don't situation (Coverity issue). For now, this is a void function.

Also, all remove failures are logged as errors. Consider possibly passing
a log level and calling lprintf() instead of errormsg(). errormsg() displays
a notice to the user, which maybe we don't want.

Ideally, I'd use atomic_bool instead, but we're using an older WinSDK for Win7
compatibility and so... can't.

Perhaps an xpdev 'protected_bool_t' should be created.

Resoles (at least) CID 488305

... so use strncpy() and TERMINATE() here (instead of SAFECOPY) to resolve
newly reported Coverity issues.

There may be other places where we're using SAFECOPY() with an unterminated
source string that would've been fine before we switched SAFECOPY from using
strncpy to strlcpy. So we should reconsider that change.

No functional change

C++ <sigh>

We don't need a .ini section separator anyway.

Just about everything in here has been implemented in v3.20 already

I suppose this should've been part of the previous commit.

Again, this is almost verbatim what v4upgrade.c did (though never actually
used).

This will allow us to change scfg_t.event[].last to a time_t value (from
time32_t) whenever we abandon Borland C/C++ in the future.

Now it's trival for sysops to view/edit when their timed events 'last run'
values. And there's no more endianness concerns. Bad .dab files, bad, go away.

After I wrote this change, I found the original conversion code in v4upgrade.c
which is almost exactly the same (except I was going to write to different
filename). Finally actually implemented this. Next up: qnet.dab