Don't count read closed channels against "is this the last one?" checks
Fix checking of channel attributes are present.
Fully close readclose channel if it's the last one.

Previously, there were (basically) three states... active, closed,
and writeclosed where writeclosed indicated that a channel close
message was sent, no more writes are allowed, and it's waiting for
the close to be acked.

This adds a readclosed state where we have received a close request
from the remote (and acked it), but have not deactivated the channel
ourselves.

This fixes a race condition where we could select a channel, then,
when we write data to it, we receive a close and the channel becomes
inactive so a new active channel is selected (effectively at random).

This is a bit suboptimal though since we still don't get a
notification when a channel is closed by the remote.  Instead, if
we use more than one channel, we need to periodically make the
channel active for writes and explicitly check if it's closed.

If you initially try private key auth for example, allow retrying
with password auth and vice-versa.  This is needed for reasonable
fallback from private-key auth since we don't know in advance
which will work, and we don't want to disconnect an reconnect.

This takes the guardrails of adding a password.  Previously, it was
ensured that a password was always added immediately after a username.
This is to ensure when using the server for example and stuffing a
list full of all the user/pw pairs, each pw goes with a user.

Instead of returning an error, this now allows adding passwords
without a corrsponding user that won't be used, and there will be
no indication of why.

Death Star mode for this feature is better than not having fallback
in my opinion.

that returns the SSH public key in the right format already.

How I accomplished this (since I tend for forget):

1. Copy the 3rdp/src/cl from a current *nix build to a system w/MSVC2022
2. Remove the I/O/eap*.c files from the project (don't exist, not needed)
3. Change the build configuration to Win32 Release
4. Resolve misc\int_api.c(700,16): error C2099: initializer is not a constant

   misc\int_api.c int_api.c
   697a698,700
   > #undef CURRENT_TIME_VALUE
   > #define CURRENT_TIME_VALUE 0x6588BADC

I guess this version of MSVC isn't "tough enough",  though apparently MSVC2017
was.

This should fix CI builds.

SSH channels, I noticed that I hand't ever finished the terminal
type/size "stuff", and while fixing that, I noticed that the hack
for SyncTERM was done wrong.

Fix the whole thing, and now Synchronet and SyncTERM both properly
support terminal type and size over SSH.  It also looks trivial to
support the SSH window size change message, but I'm not doing that
tonight.

Unfortunately, this is a patch on a patch, so is a bit fragile.
It should really have the patches merged at some point.

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.

If this solves the issue, it means that all certs for a specific
scfg will share the same compliance level.  For the mail server,
this level is OBLIVIOUS, so if it smells like a cert, it's considered
valid.

If this doesn't solve the issue, it needs to be backed out.

Should fix issue reported on IRC by Dumas_Walker

It looks like "armv7l" didn't exist when this version of Spidermoney
was released.  Just expand a previous patch to include all arm*
architectures.

It's gotten too crashy lately.

This reverts commit 64931c47.

The previous method (patching Makefile.in) didn't disable warnings when
building 'jsshell' (e.g. js.cpp).

If debugging build issues, build with VERBOSE=1 to get the very verbose
SpiderMonkey build output again.

Finally, a thread-safe version of mosquitto.dll <sigh>

Currently, sbbs.exe only
Includes non-Unix build fix in sbbscon.c for issue introduced in previous commit

Accomplished by manually removing #define HAVE_BCRYPT_H 1 from config.h and rebuilding using MSVC/Visual Studio IDE. Try as I might I couldn't get the CMakeLists.txt changes (e.g. setting ENABLE_CNG to OFF) to take effect, but this seems to have worked.

Why? Because Windows XP didn't include bcrypt.dll (a Microsoft DLL) and we don't really need it as we don't support password-protected ZIP files anyway. <shrug>

SpiderMokey is now built with ctypes, but the object is only
being created in jsdoor for now.

Remove cryptlib's -march=native to avoid SIGILL on x86_64 systems, where SBBS is compiled on a differnt host to where it is run.

This should fix issue #324

- Update SpiderMonkey config.guess
- Include patch for SpiderMonkey Mozilla bug 638056

This may fix various out of resources issues.  Here's what the source
has to say about this number:

/* The maximum number of objects.  By default we use a fixed limit set to an
   appropriate large-enough value because the only time anyone that would
   really be creating thousands of objects is if they're leaking them and
   setting a fixed limit means this is detected without the code having to
   run for days or weeks leaking handles, however we allow a dynamically-
   configurable limit set via CONFIG_NUM_OBJECTS if someone really needs to
   use vast numbers of objects */

This was preventing cryptlib from working with socket descriptors
over FD_SETSIZE despite being patched to use poll() to avoid the
issue it's protecting against.

May fix the various SSH/SSL internal error issues.

Per https://man7.org/linux/man-pages/man3/pthread_yield.3.html
	This call is nonstandard, but present on several other systems.
        Use the standardized sched_yield(2) instead.

Should fix #299.

We don't support platforms where '/' doesn't work as a path element separator.

Just don't check the python version at all.  If your python is older
than 2.5, you're already having other issues.

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

Just some more macOS silliness.