For regular user QWK Relpy packet uploads only, if no timezone is specified
(e.g. via @TZ kludge or HEADERS.DAT), then over-ride the message's "posted"
date/time with the current date/time since we're going to set the message's
timezone to the BBS's local timezone as well.

This is a fix for issue #783 reported by Chris Jacobs.

If/when we support user-specified timezones, then this likely would be a
place where we'd want to use the user's timezone.

From todo list on Vertrauen, not in GitLab (shrug)

When no files with extensions are found, though they matched the glob()
pattern, a NULL pointer deref would result (segfault).

This could happen if the only files matching the pattern had no extenions or
were directories (not files).

Fix for issue #779

... this was the cause of some observed unnecessarily high disk/file server
(Samba) utilization, as we call getnodedat() a lot. utime() opens and closes
the file, which was already open - and we're not modifying the file, so
updating the 'modification time' here is wrong anyway.

Disabling this 21-year old bit of logic resulted in a pretty dramatic
reduction in Samba (smbd) CPU utilization on Vertrauen.

If a BBS actually needes this hack (e.g. for NFS compatibility, as Deuce
eluded in the comment), they'd be better off just setting the "Keep Node File
Open" node setting (in SCFG->Nodes) to "No".

I'v been getting errors locking user.tab (for read) for a while (over samba),
so hopefully this helps. The lockuserdat() total timeout duration extends from
about 5 seconds to about 45 seconds (with an incremental back-off).

Implement the same lock-retry logic/limit in putuserdat().

At least 512 bytes per call.

Eliminates GCC warning about not checking return value of write/sendsocket()

The expansion of LF to CRLF (with TG_EXPANDLF) is on receive.

For Nelgin

I'm not clear why Coverity suddenly thinks that getstr() doesn't
nul-terminate strings, but whatever: NUL-terminate the buf before passing it
to getstr(). <shrug>

HANDLE_PENDING() macro returns from the calling function (without freeing
allocated resources), so don't use that here.

Only the last node number specified would be listed before this fix.

No longer claim that 'list' is the default action (it's not).

If you want to list nodes, you need to specify the 'list' action.

Fix for issue #772

If an array argument is passed to these methods, the stringified contents of
each array element value will be sent to the remote server after connecting.

This is to support Nelgin's request of sending some strings to a server after
connecting. There's no way to insert pauses between the sent strings or wait
for certain output from the remote - that's beyond this scope/capability.

... since these methods only feed the keyboard buffer.

Add an optional 'insert' argument to console.ungetkeys() - default is false
(append).

Add a new version of console.ungetstr() which feeds the passed characters
directly to the receive input buffer. Now returns bool indicating success.
Existing scripts (if any) that use console.ungetstr() should continue to work
just fine.

This is anticipation of telgate.js being able to stuff strings (e.g. username,
password) into the input buffer and those chars/keys being passed to the
remote (gatewayed) telnet server. Since the telnet gateway reads directly from
the receive input buffer (ignoring the keyboard buffer), we needed a way to
stuff strings of characters into the receive input buffer directly and that
sort of exposed the weirdness of the existing console.ungetstr() method:
- it didn't return a return value (not indication of failure)
- it didn't support an 'insert' operation (even though the underlying C++
  method does)
- it didn't use the sbbs_t method that already existed for feedding a string
  of characters into the input/keyboard buffer

Calling exit() causes JS_ExecuteScript() to return false (same return value
as if there's a syntax error) - so if we always set exit_code in exit()
(even when not passed a parameter) and then use that exit code if the property
is defined, then we get the -1 return value from js_execfile() if the script
is terminated prematurely without using exit().

This fixes the issue introduced in the previous commit where scripts that
call exit() - without any parameters, were causing errors to be logged about
scripts (e.g. timed events) returning -1.

js_execfile() now returns -1 when JS_ExecuteScript() return false (failure).

The main command-shell loop will now terminate when js_execfile() returns
anything but 0 (success), similar to how PCMS (Baja-compiled) command-shell
.bin file parse errors are handled.

This is a fix for issue #340

Another idea would be to store a history of mail save paths and allow the user
to scroll through them/choose with the up and down arrow keys, but that goes
beyond the original feature request. So this just stores/reuses the last
successfully used path/filename.

... as appears to have been the intent

And really, more importantly, the msg header field_list array length would
always be interpretted as 0-length!

... introduced in commit 54523145

... introduced in commit 54523145

Include -pause and -loop options in usage help output.

Don't delay (sleep) one second when looping and -pause option is used.

Flush the output before waiting for key-press (-pause option is used).

This should all address issue #365. Sorry for the long wait.

When a user has a "default download protocol" selected (configured for their
user account), don't display a menu of file transfer protocols when we're
just going to auto-select their default anyway (e.g. when downloading a QWK
packet).

This change also introduces an argument (%s, the protocol name) in the
StartXferNow text.dat string, so that if/when the user forgets which default
download transfer protocol they had selected, they'll be reminded ("oh yeah,
I need start an XMODEM download!").

This fixes issue #767

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.

The calling script will still terminate if it does this, but at least the
caller will get a useful JS exception.

Related to fix for issue #769

I'm not sure under what script conditions this could happen, but apparently
Nelgin was able to produce this null pointer deref (and segfault) using
DDMsgReader. This should fix issue #769

See issue #765 for background.

to the getkey inactivity timeout.

By setting a socket timeout shorter or equal to the getkey timeout, the getkey
timeout effectively does nothing.

If a sysop doesn't want this warning to do anything, then no need to save
and restore the current (last displayed) line of text.

We've had this value as the default in sbbs.ini for a while now, so should be
safe to use as the upgrading-sysop (who wouldn't have this value in their
sbbs.ini file, most likely) setting.

Not all default sbbs.ini values are true "defaults" (meaning, if they don't
exist in the file, then same value would be used) - but we should do an audit
and correct those mismatches at some point.

looks better, more consistent with the log messages before/after it.

We removed the large-scope 'i', but didn't update the Unix-only blocks of code
(dealing with UNIX domain spy sockets).

This is just a code quality (readability) improvement. No functional change.

The other server stats (e.g. error_count, served) are zeroed upon startup, so
the highwater mark should be zeroed too.

Like the other servers.

A sysop likely would want to know which services/protocols had what
utilization (as a portion of the total highwater mark), so that'll have to
be added later.

We don't log highwater valeus of 1, though those are published to MQTT.

Not dealing with 'services' server yet, cause that's kind of tricky with the
sysop likely wanting to know per-service stats (served counter, highwater
mark, etc.)

Only log the hightwater mark when it's > 1. :-)