Improved fallback expiry

[traines-source]

Resolving the "todo: fall back to tU.trip.start_{date,time} + buffer if available? – handle canceled trips without sTUs!".

I think it is imperative to have very long ttls for cancelled trips, since these are in some way the most important realtime updates and they might be known longer beforehand, i.e. the fallback based on getNow() when no start_time is available (which is usually not available) is dangerous. Correct me if I'm wrong, but in the current impl, cancelled trips are basically never ending up in the output feed, or more precisely only for 5 min/the ttl. Unless they are usually coming repeatedly in the DIFFERENTIAL input? (Your VBB feed does have astoundingly few/no cancelled trips when I checked.)

Another note: Depending on how you generate the input ndjson, sTU.arrival.time may never be an integer, at least when generating it with print-gtfs-rt-cli, because then it looks like "time":{"low":1736496420,"high":0,"unsigned":false}. And for feeds using relative delay instead of time, the fallback with the fallbackTripDuration will also always be used, so it also needs to be very long (maybe 6 hours is still too short). I have not found any hint in the draft standard on how to handle this.

From my experience in the last days, a ttl of 6 hours still only uses a couple of hundred MB of RAM even for big feeds like DELFI.

Since I fiddled around quite a bit with that, I have also added an example to read input from other processes via a named pipe and write the full feed to disk on every update.