The old matching process which tracked mode A values as pseudo-aircraft
got very, very expensive with a large number of mode A/C messages (and
with lots of single-bit errors, which seems common with a Beast doing
the reception)
Instead just count A/C messages directly into a 4096-entry array (which
is very fast) and periodically scan the mode S aircraft list to see if
we can match anything up (which is fixed overhead + cost proportional
to the number of mode S aircraft)
This gives us a better chance of the response fitting in a single
write() call (if it doesn't, it's going to get truncated, because
the internal webserver is really simple)
The old logic had a number of problems, including:
* sending heartbeats on all service types if any type needed
a heartbeat
* sending a heartbeat multiple times a second if there was a
service type that was idle but didn't generate traffic when
an empty message was sent (e.g. FATSV)
Rewrite it all so that heartbeats are explicitly tracked and handled
per service type, rather than by sending a dummy message.
Also switch to mode A/C messages for the beast/raw heartbeat, as
it's a bit more compact and less likely to mess with Mode S state
(an all-zeros Mode S message actually looks valid)
Notice synthetic mlat messages by looking for messages with a magic
timestamp value. If they arrive, tag the derived data as mlat-derived.
Don't include mlat-derived output in FATSV output to avoid loops.
In particular, not guarding in flushWrites() meant that we
could end up trying to write to an uninitialized writer
(where writer->service == c->service == NULL) and crashing.
The DF17/18 values are generally more trustworthy as they have full
CRC coverage. Errors in the CRC bits of a DF0/4/16/20 message can
result in the contained altitude being attributed to the wrong aircraft.
This lets different things dynamically create the services they need,
and sorts out the horrible hacks that view1090 used to make outgoing
connections. Now you can explicitly create a service and tell it to make
an outgoing connection.
This means that view1090 can now just set all the ports to zero (to disable
the listeners), do a normal net init, then explicitly construct the beast
input service without a listener and tell it to make a connection as needed.
