Don't indicate stop has been updated when NO_DATA is defined

[optionsome]

Summary

The realtime indication in the APIs is changed to be false/SCHEDULED for stops that have NO_DATA update from GTFS RT instead of true/UPDATED. This makes it possible (together with #3960) to not have stops marked as having realtime updates if SKIPPED updates are given for other stops in advance before there are time estimates available.

Issue

closes #3961

Unit tests

Added

Code style

Have you followed the suggested code style?
Yes

Documentation

Not needed

Changelog

From title

[optionsome]

Tests should be added but the tests for GTFS RT updates are currently ignored, see comment #3960 (comment)

[leonardehrenfried]

We talked about this in the meeting and came to this conclusion

• use a single a array for the realtime state
• use top level state

[optionsome]

I've updated this pr now so it replaces the boolean flag arrays with an enum state array. I'm not a SIRI expert, so I don't know for sure if it's possible to set a stop as recorded and cancelled at the same time, for example. If it is, is that some information we should keep or should we just store that the stop is cancelled? I think with the current implementation the cancelled state could be overridden by the SIRI updater with recorded/prediction in accurate states which is probably at least a problem if the data allows it.

[optionsome]

I've updated this pr now so it replaces the boolean flag arrays with an enum state array. I'm not a SIRI expert, so I don't know for sure if it's possible to set a stop as recorded and cancelled at the same time, for example. If it is, is that some information we should keep or should we just store that the stop is cancelled? I think with the current implementation the cancelled state could be overridden by the SIRI updater with recorded/prediction in accurate states which is probably at least a problem if the data allows it.

[optionsome]

As discussed in the previous developer meeting, I updated the SIRI updater code so that it's not possible that cancellation information is overridden by recorded/inaccurate prediction @lassetyr and @MikaelJarfors .

I still need to update the serialization version id because of the changes to TripTimes right?

[MikaelJarfors]

Me and Joel had a discussion surrounding this and agreed that it would be good to implement a small unit test that protects the order of the assignments made.

[optionsome]

I looked into creating tests yesterday but it didn't seem like the SIRI trip updaters had any. It might take some effort to create tests. Should I still try it or do something else to document this use case?

[optionsome]

We discussed this today and came to the conclusion that the tests will be added in some other pull request. As there had been some changes to dev-2.x since the last update on this branch, I rewrote the implementation but the only minor differences to the previous implementation are in the SIRI code.

[optionsome]

I remembered that I can now add more tests for the GTFS RT as some of the old tests were fixed. I'll do that.

[leonardehrenfried]

The GTFS(-RT) parts of this are good.