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.

The design is to #include eventwrap.h for cross-platform source

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

./scfg.h:80:9: warning: 'SUB_HDRMOD' macro redefined [-Wmacro-redefined]

This is always going to call the terminal server's lprintf function (when used
with libsbbs.so/sbbs.dll) which is probably not what was intended.

Resolve reported clang warning:

inkey.cpp:592:20: warning: implicit conversion from 'long' to 'int' changes value from 2147483648 to -2147483648 [-Wconstant-conversion]
         if(!term_supports(MOUSE))
             ~~~~~~~~~~~~~ ^~~~~
 ./sbbsdefs.h:574:19: note: expanded from macro 'MOUSE'
 #define MOUSE           (1L<<31)                /* Mouse supported terminal                             */

This is hacky cruft here. We shouldn't have the declaration in multiple
places. It probably shouldn't be in sbbs.h.

load_cfg() calls free_cfg() before do_cryptInit() is called, so the ssl_rwlock
was uninitialized here.

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.