This is adapted from the FlightAware fork, with some cleanup and
modifications needed to work with the net-cleanup changes.
Inclusion of "verbatim" TSV data read from an AVR-format input
connection is not supported.
realpath() returns a heap-allocated buffer if given NULL for the destination buffer.
This must be freed by the caller; dump1090 does not do this.
Instead of worrying about freeing it, take the simpler approach of just providing a
stack-allocated destination buffer.
Mostly refactoring the common code that was duplicated
between the different output types so that there aren't
many copies floating around.
This introduces "struct net_writer" to store the state of a
particular type of output service - buffers, time of last write,
connection count etc. prepareWrite() / completeWrite() give access
to the buffer and handle the actual writes and flushing when needed.
Heartbeat and time-based flushing move into a generic periodic-work
function.
Update the SBS output code to use the new infrastructure. This makes
a big different to CPU use when under load.
When we read from some client A, we may end up forwarding a message to other
clients. If we forward to some client B and there is a write error, then
we close B and remove it from the client list. However, if before this happened
A->next == B, then the read loop will still be holding on to a pointer to B,
and we crash.
As it's unpredictable what clients could be closed at what point, the simplest
approach is to retain closed clients in the list until we are at a point where
we know there are no stray pointers on stack, and only then modify the list.
This also simplifies anything that has to loop over clients, as it doesn't need
to worry about the current client being freed under it.
Client disconnection appears as a read of 0 bytes.
Without a test for this, dump1090 continues to poll that client forever.
Also, read() may return EWOULDBLOCK as well as EAGAIN
for "no data right now", so handle that.
I don't know if there is an equivalent Win32 bug here as the Win32
interfaces seem subtly different to vanilla POSIX.
The following test/break can probably be removed if Win32 needs
the same fix.
For remotely received messages that have a mlat timestamp, we have no
useful way of turning that timestamp into a wallclock timestamp, so
don't try, or we'll just produce wildly wrong results (_days_ in error)
