Fix consolidation stop returning original stop ID.

[miklcct]

Summary

This PR has two changes to fix #6032 .

Fix a core issue of Timetable not linking back to the referenced TripPattern

The bug shows from GraphQL in the sense that the stops returned by the pattern are the primary stops, but once the StopTimes are loaded from the timetable, the stops returned are the original, secondary stops.

In the original core code, the Timetable links back to TripPattern which is supposed to create a circular reference as commented. However, it isn't true once the TripPattern is copied. The change to core code makes sure that Timetable instances are never shared across multiple TripPattern instances, and each Timetable instance has a link back to the owning TripPattern.

The sameAs method in TripPattern is updated to work on content equality of the timetable, instead of the equals() method, which can't be overridden because timetable is mutable and is placed in the set, which requires identity equality.

Use the primary stop object in the legs even if the secondary stop names are to be used.

This allows clients to programmatically query the stop data, while showing the secondary stop names to the user.

Unit tests

Added for static timetables. However, real-time updates with consolidated stops aren't tested yet.

Documentation

None.

[leonardehrenfried]

I'm the author of this sandbox feature and I urge you to not use it and fix your data instead.

This was created for a very special deployment under very special circumstances with very specific use cases in mind. It not touching the core code at all was one of the original conditions for having it, so that's why it is the way it is. Also it is left so that it can be very easily ripped out. I will do so when the deployment has moved off it.

Our rules for sandbox features are that the authors have control over them and I don't want to collaborate on it as IMO it should not exist. Again, please fix the data instead.

Some of your changes to the core model might have merit, but changing the core entities is very, very difficult and requires a lot (weeks) of coordination with the core team. If you want to do it, it helps to show up to the dev meeting.

[miklcct]

How is it possible to fix the data across two different data feeds w.r.t. to finding legs using nextLegs and previousLegs? I don't think that's possible in the core code.

[leonardehrenfried]

You need to merge your feeds. If you want well integrated results you need well integrated data. It's difficult, I know, but worth it.

[miklcct]

I don't plan to publish the core changes separately as the circular reference issue only appears when TripPatterns are replaced after building the timetable, which only happens when using this sandbox module.

I am going to prioritise making a combined GB-wide feed (GTFS.pro has done that which helped us developing our first prototype, but we have better quality data for National Rail) which has already been in our business plan, so we can disable this feature.

The main use for this is that some Underground and National Rail services use the same physical platforms on the ground, but there are different NapTAN stop codes for Underground and National Rail.