[zcsahok]

The motivations for reworking the cluster interface are:

• Slow start-up: addressing the annoying "still there...not dead" messages that eventually block the system if the cluster is inaccessible.
• Sporadic cluster messages: random cluster messages were appearing on the UI sporadically.
  I decided it was easier to just rewrite the code than to try and untangle the mess of UI and backend logic, especially since most of the current code is just dead and isn't even being used.
• Unintuitive cluster CLI: the cluster split-screen command line interface is difficult to exit,
  particularly when accidentally entered it by typing a colon in the call input field.

The new design moves cluster handling to its own dedicated thread.
To ensure no UI actions occur within this thread, communication with the rest of the TLF (main and background threads) is performed via thread-safe queues. The main RX queue is fed with lines read from the network, serial, or FIFO device, while a similar TX queue is used for sending messages into the cluster.

The tasks of the cluster thread are to:

• Connect to the configured endpoint.
• Read available data and post it into the RX queue line-by-line.
• Check the TX queue and send its contents.
• Upon a connection break wait and restart the process.

Cluster-related features like band map or spotting are not affected.
Current cluster information is shown on :INFo screen.

I've been using the code locally for several months, but there may still be some rough edges.
These will be addressed along the way.

Starting with a quick cleanup of an unused define. After this, I'll remove splitscreen.c and sockserv.c and begin incrementally rebuilding the functionality.

[zcsahok]

Commented-out parts marked with CFIXME.

[zcsahok]

The logic for forwarding cluster messages to LAN nodes is as follows:

Source	Forward to LAN
cluster	yes, as CLUSTERMSG, but see Note1
CLUSTERMSG from LAN	no (old code for some reason did call addtext() with lanspotflg=false, maybe relying on cl_send_inhibit)
internal spot (Ctrl-A or BMAUTOADD)	yes, as TLFSPOT via add_local_spot()+add_to_spots()
manual cluster spot (Ctrl-B)	no (but see Note2), calls add_cluster_spot()+send_to_cluster()
TLFSPOT from LAN	no

Note1: upon receiving a CLUSTERMSG, a node stops transmitting further
CLUSTERMSG messages by setting cl_send_inhibit = true.
This ensures that only a single node acts as the cluster source.

Note2: manually generated cluster spots follow the standard cluster data path:
they are submitted to the cluster, received back through the cluster interface,
and processed using the normal cluster spot handling logic.

The previous implementation relied on the global lanspotflg (setting it to true suppresses forwarding), shared between the main and background threads, creating a potential race condition. This has been replaced by the thread-safe functions add_cluster_text() and add_other_text().

[zcsahok]

Now TLF starts up with the new cluster thread, spots are shown on the band map.