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.

... weird this wasn't required before now.

Removed obsolete DSTSEDIT target.

Resolves 'make sexyz' build issue mentioned in issue #690

Fix up the 'utils' target a bit

List all the add'l sub-build targets in 'help' output

Add -host=<name> option to set the hostname to use for alternative sbbs.ini
file.

Fix CID 471381

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.

... wasn't accounting for length of the 'top' buffer (when supplied).

Also, for raw input mode:
- flush the input buffer (stray LF) before accepting input
- turn off raw input mode if run out of bytes (max lines/length reached)

I was investigating the reported error by Nelgin:
  !ERROR in writemsg.cpp line 1214 (msgeditor) checking
		"max lines (20) exceeded" access=46
which I was unable to reproduce, when I encountered the issues addressed
in this commit.

... for server configuration dialogs

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.

We need to get the NextItem *before* we delete the current one.

I'm not sure why this was in there, but removed it as appears to have
no effect:
	if(ListView->Selected == NULL)
		break;

Include the time-span of the login attempts in the reason string.

Interestingly, qwk_timeout was already read (but not set) as a duration.

Add "NO_CGI" to the default Web Server options.

It is almost 2024 after all. :-)

Every server should have *some* limit to protect against DOS attacks.
Every connected client consumes a socket, a thread, some memory, none of
which are infinite resources.

... unless the full path was specified.

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

May help nail down issue with keys.

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.

Remove some redundant redundancies, redundantly

it's only called from load_cfg() which has already set it to -1.

We also don't need to check prepped twice to make sure it's extra true.

Ctrl-A in the Failed Logins dialog now selects-all rather than copy-all (just
use Ctrl-A, then Ctrl-C to copy all).

warning: result of comparison of constant 100000 with expression of type 'uint16_t'
(aka 'unsigned short') is always true