This should fix the sftp hangs...
While FreeBSD will return EDEADLOCK when a mutex would deadlock,
Linux will do what I ask and deadlock.

Since we're not checking the return value of pthread_mutex_lock(),
this would go completely unnoticed on FreeBSD, resulting in the
mutex being unlocked early and all sorts of unprotected accesses
would happen, potentially doing crazy things.  On Linux it just
deadlocks, and taking a peek at the thread backtraces makes the
problem obvious.

So, point to Linux for making life more correct for people who
do incorrect things (locking without checking the return value).

I'd also like to thank nelgin, for sticking with me on this issue
and being my gdb puppet.

And really, this commit should be shared by all the contributors
who... 𝆺𝅥𝅮𝆺𝅥𝅮𝆹𝅥𝅯𝆹𝅥𝅯

This prevents the case where input_thread() accepts the sftp
connection and calls init_sftp(), then answer() does the same thing,
clobbering the previous state.

but does not yet have a session type.

Also, fix what appears to be a fairly blatant memory leak.

If there's an error setting the channel or getting the channel
type, give up on the session immediately.

In this case, just accept whatever we get info on as the "first" one.

Likely fixes #728

If the SSH_ANYAUTH option is set, the server will accept the "none"
authentication method, and not even suggest the client send a
password or public key.

The client must still send a user ID, but we just ignore it
completely and don't even log it.

This blindly accepts whatever authentication the remote offers, but
does not log into the BBS, dropping the user at the login prompt
instead.

Closes #726

You're welcome Keyop.

The other 500 times are implied.

The reason the comparison was changed to <= 0 is to do an explcit
check that eliminates negative numbers rather than the implicit ones
with the greater-than checks.

It seems that GCC is concerned that we can't create a sftp_dirdescriptor_t
or sftp_filedescriptor_t?

If user is being kicked off for being on "More than one node at a time", then
don't send a message to other any other nodes that the user logged-on
successfully (they haven't). Previosuly, it'd send messages to all the
lower-numbered nodes that were in-use (but not by the same user).

Reported by Nelgin.

User disconnection will trigger auto-terminate (eventually) as well. But only
in the terminal server.

JS console.inkey() and friends use this as the underlying function to get
input from the TCP socket.

This might address issue #725

Hoping Nelgin will let us know.

For some reason, I committed test code that commented-out the actual call
to js_IsTerminated() which avoided the unnecessary error log message. I guess
I was testing to confirm the change actually worked. <shrug>

Address this problem report:
<nelgin> Right but I'm getting a lot of "logged off" without ever having a "logged on"
<nelgin> Node 3: Keyop logged off 02/26/24 18:35:45
<nelgin> Node 5: Keyop logged off 02/26/24 18:36:39
<nelgin> There was never a login, so there can't be a logoff.
<nelgin> That would break the time-warp continium.
<nelgin> time-space whatever :)

This could happen when non-G-exempt user was kicked before logon completed due
to already being logged onto another node. This change should fix that.

If errno is 0, it's definitely no proividing anything of value here. Of
course, sometimes errno might be non-zero and still be unrelated to the error
message. <shrug>

For Nelgin:
!ERROR 0 (Success) in exec.cpp line 644 (js_execfile) compiling "something.js" access=0
<nelgin> I don't quite get why a successful execution is logged as an error

Resolve build warning about unused var

Also, resove a new gcc warning about signed/unsigned compares.

Converts UTF-8 output to CP437 equivalent (cterm doesn't yet support UTF-8).
Fixes issue #717 (more or less).

The terminal dimensions are also read from the node*/terminal.ini file, but
aren't applied to the cterm runtime (though maybe they can/should be, probably
requires a cterm re-init).

... so no need to parse/strip them here.

This eliviates the issue of partial/corrupted UTF-8 sequences when spying on a
node serving a UTF-8 terminal.

_fintfirst() is declared in the Mingw-w64 headers as an intptr_t,
which tracks.  Can't find _findfirst on MSDN, so that's good enough
for me... let's see what the pipeline says.

The definition of vsnprintf as _vsnprintf didn't seem to hurt the build
(as well, for Borland)

The GNU_SOURCE build of this function was (sometimes?) just returning the
string and not actually copying it to the passed buf. This is consistent
with the GNU manpage on strerror_r():
"This may be either a pointer to a string that the function stores in buf ..."
but was inconsistent with all the other build types of this function.

Also updated to use strlcpy and write the problematic error number to the
default string (if unknown).

As Nelgin pointed out, a Socket.connect() failure for reasons of address/host
lookup failure would report a stale/nonsense Socket.error/error_str value.

This change required us to query/store the socket API/getaddrinfo error string
at the time of failure (for the Socket.error_str property value) rather than
converting from number to string at the time the property is read.

This does mean that sometimes Socket.error is a errno value and sometimes its
a getaddrinfo (EAI_*) error value. Since the EAI_* values are negative, it
should be obvious which is which.

Reads the new(ish) node*/terminal.ini file when it's changed to determine
the connected-client's terminal type/dimensions. Now reports the terminal
details in the spy form title/caption and if it's UTF-8, does a real-time
translation to CP437 (since F. Piette's terminal lib only supports CP437).
There is a bug here where if the data read from the RingBuffer is a
partial UTF-8 sequence, it isn't decoded correctly. Fix that later (?) if it
actually bugs anyone.

There's no PETSCII conversion/support added here. I expect to someday replace
this entirely (likely with something that uses cterm), so didn't want to
invest too much time into this.

But at least now spying on non-traditional ANSI-BBS clients isn't so terrible
to look at.