While we're hacking on that, make a first attempt at a generic
Atom access framework.

The only actual visible change that should occur here is that the
window will not resize larger than will fit on the current desktop
between various WM widgets (panels and menus).  I've been considering
this change for a while, but now that fullscreen support is present,
it doesn't really take anything away.

Just use _NET_WM_STATE protocol for fullscreen... messing around
with the methods is pretty painful.

Because we're not messing with other stuff, we can likely remove
all the code I added to prepare for this. :D

Testing this really highlighted other broken bits, so a bunch of
that has been fixed as well... including the bug that Ragnorok
hadn't reported yet as of last time I looked (corrupted screen when
maximixed).

Or even weirder, u_long?

And dereffing a ulong/u_long pointer where you expect to find an IPv4 address?
Yet even weirder still.

Fix that spit: It appears in_addr_t is defined on all platforms (?), so use
that type instead.

No known sightings of these sites actually being the location of a segfault,
but as we learned from the segfaults in rblchk(), the first entry in the
h_addr_list can be NULL in some cases.

I'm not sure why this one only started popping up now, but h_addr_list is a
NULL-terminated list and it makes perfect sense that the first entry could
be the NULL-terminator.

gethostbyname is obsolete/deprecated and we should address that in a separate
commit.

A bunch of possible (but often, not really) use of undefined values.
Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets).

Other than some added diagnostics upon some of these unexpected syscall
failures, there should be no change in behavior from this commit.

This is the last feature that SDL mode provides that X11 mode is
lacking.  I rarely use it myself, but it should be there.

Apparently the mosquitto.h won't always be installed in /usr/include on
all systems (e.g. Deuce's FreeBSD gitlab-runner system)

Previously, if there was more than one work area, this would be
an infinite loop, re-reading the first workarea repeatedly.

Reported by Ragnarok (thanks!)

Fix infinite loop in bitmap_drv_init_mode() if scaling results in
larger than max size.

This uncovered an issue in resize_window() which would cause the
screen to be corrupted due to vstat not agreeing to the actual window.

This was ending up using an uninitialized value

No need to build twice just to create the bundle.

In theory, a crazy person could grab it every day and upgrade it.

You still need to specify it, but you can create a /usr/local dpkg
now if you don't.

It's pretty important to specift PREFIX here right now since it's
not actually used in the paths, which means there would be a mismatch
between where the files are installed and where the data lives.

This is fairly easy to fix, but I likely never will.

It appears its matching based on the class, not the application.
Since this was hard-coded to CIOLIB based on the idea of using
resources to customize all CIOLIB windows, this didn't match the
SyncTERM .desktop file, so ChromeOS assumed it was "something else"

Add yet another ciolib_initial_* variable to set this, and she's
finally good!

Part of my apparently never-ending quest to get the icon to show up
for the SyncTERM window on ChromeOS.

Cyan may have a better fix. <shrug>

Implied by _NET_WM_PID being set, so may as well do it.

Seems like a good idea, should allow WMs to kill hung processes and
stuff like that.

It was redudnant having "External Editors" under "External Programs" (they're
all external, yeah?) and of course, "Editors of what?"

So yeah, existing docs are now all wrong. :-)

The XSynchronize disablement is the most important here... didn't
realize it defaulted to enabled, which has been slowing down a *lot*
of stuff for a long time... not that there's much left that benefits
from disabling Synchronized XLib except this new terrible icon thing.

Keyop reported an issue via irc whereby a user that failed to download a file
would leave the node "hung" in "downloading via telnet" node status even
though the user had long since disconnected and the log reflected that the
terminal server was aware of this:

term Node 4 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 4 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 4 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 4 connection reset by peer on send
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 disconnected
term Node 4 !ERROR 32 sending on socket 102

and

term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 3 connection reset by peer on receive
term Node 3 !ERROR 32 sending on socket 96

These nodes were then locked up in call to passthru_socket_activate(false)
as reported by gdb, e.g.

Looking at passthru_socket_activate(), the deactivation path (called at the
end of external() in this case), it was clear that this could be an infinite
loop in the case the user had disconnected:

    do { // Allow time for the passthru_thread to move any pending socket data to the outbuf
        SLEEP(100); // Before the node_thread starts sending its own data to the outbuf
    } while(RingBufFull(&outbuf));

These flush/purge loops aren't strictly needed if the user has disconnected,
but as can be seen by the above logs, the terminal server may not know that
(the socket may not indicate disconnect) before passthru_socket_activate()
is called by external().

So... worst case, just do the activation and deactivation buffer flushes
and purges for 60 seconds.

On Linux, this changes the program name shown in top.

This allows X11 stuff to work properly.