Use new rwlock for ssl certificate.

See merge request !386

Instead of tight loops with 1ms Sleep()s in them, add events for
zero readers and zero writers that we can wait for instead.

Unfortunately, since Events aren't interlocked with a critical section
like condition variables are with mutexes in pthreads, we can't
rely on this for race-free code, so for read locks, we still may
spin under write pressure.

Various bits of broken no longer broken.

Since we can't bool anyway, may as well.

It would be nice to use TLS for the recusrion counter, but on Windows,
it looks like TLS in threads created after the object is created is
uninitialized, so we would need some kind of thread start hook thingie
which just seems like too much work.

Instead, rely on the old standby single-linked list to track.

It looks like Windows actually uses the name for matching existing
events, so if two events have the same name, they end up being the
same object.

Recursive read locks, non-recursive write locks.

Currently the "wrapper" is just the POSIX API.
We may not need the pthread_rwlock_timed??lock() functions, and even
if we do, we like want a different wrapper that takes a ms timeout
instead of an absolute time.

On Win32, the name param is an LPCSTR which apparently is Microsoft
talk for const char *.

In C we're allowed to do whatever we want, but in C++, this matters
more.

Just running git commit --amend doesn't do -a it seems. :)

This should fix a long-standing issue where someone could connect to
the SSH port and do nothing, which would prevent other incoming
terminal sessions from being accepted until it times out.

Unfortunately, this means that Synchronet can't send any data until
authentication is completed, which means useful messages about why
you're being disconnected (ie: "Sorry, all terminal nodes are in use or otherwise unavailable.")
as well as usless information nobody ever cares about (ie: The IP
you're connecting from, that it is resolving your hostname, etc).
can no longer be sent to the user.

Reported by Max (WESTLINE)...

Introduced in commit 75c5c9e5, since we are now calling the set_state()
callback periodically, and in sbbsctrl, it sets/resets the pause button
checked (depressed) state in response to this callback (should it?), this was
resetting the pause button checked/depressed state peridically (at the
configured sem file check interval, default 2 seconds).

The fix: if the new server state is the same as the previously set server
state, don't call the set_state() callback. I considered this as a potential
optimization when I first wrote that commit, but didn't see any obvious
downside to calling the set_state() callback redundantly. Now that I see a
downside, let's implement this saving/checking of the state to avoid
redundant "set" calls.

... with a socket descriptor value of -1.

The 5th character must be a digit.

Prevent future stupidity such as happened with recently added and then
fixed NODE_USER @-code.

Since "NODE*" is a match for a node number status (ugh), and this comparison
happened before the comparison for "NODE_USER", we'd never hit that condition.
Thought I tested this before original commit, but I guess I did not. Oops.

This recent enhancement (Commit 61a3ab2d) introduced security and usability
concerns.

So I created (and am now using where requested) a wrapper for formatting
text.dat/ini strings which will automaticlaly detect @-code encoded strings
and expand/use them *only* (instead of printf %-specifiers).

This might impact issue #696 since although unintentionally, it actually was
possible to mix @-codes and %-specifier usage in certain (node status)
text.dat/ini strings, but that should not be possible now. It's either/or:
@-codes or %-specifiers, not both.

Needed for exactly reproducing built-in node status string formatting using
@-codes (only).

Note: format specifiers (e.g. %s) cannot be combined with @-codes (use one or
the other, not both).

Fixes issue #696

If you need additional text strings to support @-codes, you'll have to specify
them explicitly in feature request issues.

We have checks/loops/timeouts waiting for active clients to disconnect and
child thread threads to terminate whenever shutting down or recycling already,
so this should be safe. This pretty simple change fixes issue #236 (can't
terminate server under heavy load).

Also as part of this commit, introduced the ability to "pause" a server
(prevent it from accepting new connections) with the ctrl/pause semaphore
file or via the MQTT server/pause (and resume) topics. This feature is useful
when debugging server issues where you don't necessarily want to fully
shutdown/terminate the server, but don't want any new connections to be
accepted (the listen backlog will fill up with incoming connections though).
Unlike a server shutdown, a server pause can be "undone" via MQTT (by
publishing a message to the "resume" topic).

The "pause" semaphore file is just an "existence" semaphore file - its
date/time stamp doesn't matter. If the file exists, the server will enter
a paused state (and periodically log messages to that fact) until the semfile
is deleted.

This server pause feature is not the same as the pause button function in
sbbsctrl, which just pauses server log output.

In this case, we don't care what the time stamp on the file is.

that doesn't log an error