Introduce RealtimeUpdateContext

[vpaturet]

Summary

Real-time updaters use instances of TransitService to look up transit data. Currently these instances are created at construction time.
This is problematic since TransitService instances maintain a reference to a frozen version of the TimetableSnapshot that is not updated after construction.
As of today this does not cause any issue, since the real-time updaters update directly the collections in TransitModelIndex, and the TransitService looks up data in TransitModelIndex.

However #6007 changes this behavior by storing the real-time updates in indexes in TimetableSnapshot, making previous real-time updates invisible from the real-time updaters.
Among other regressions, this prevents the EntityResolver from identifying already created extra journeys, and leads to the creation of duplicated trips.

This PR refactors the real-time updaters so that they use TransitService instances that refer to the TimetableSnapshot buffer, thus giving access to all applied real-time updates (including uncommitted ones).

This PR is a prerequisite for #6007
This PR supersedes #6018

Note: the refactoring consists in:

• Modifying the GraphWriterRunnable interface so that it accepts a RealTimeUpdateContext as a parameter.
  RealTimeUpdateContext gives access to a transit service that points to the TimetableSnapshot buffer. Other entities exposed in this interface (EntityResolver, SiriFuzzyTripMatcher, GtfsRealtimeFuzzyTripMatcher) are also aware of the latest applied real-time update.
• Refactoring the real-time updaters in order to make use of the instances of TransitService, EntityResolver, SiriFuzzyTripMatcher, GtfsRealtimeFuzzyTripMatcher provided by the RealTimeUpdateContext, exclusively in the context of a GraphWriterRunnable (where it is safe to do so).

Note: the SiriFuzzyTripMatcher is now instantiated only once in the RealTimeUpdateContext, making it possible to remove the static singleton logic that made it difficult to test.

Note: The SIRI-SX and Alert updaters still make use of a TransitModel instance. In practice they just need access to the StopModel, which is (currently) immutable. These updaters could be refactored in a follow-up PR to use only the StopModel instead of the TransitModel, making the intent clearer.

Issue

No

Unit tests

Added unit tests,
Updated unit tests.

Documentation

No

[codecov]

Codecov Report

Attention: Patch coverage is 36.79245% with 67 lines in your changes missing coverage. Please review.

Project coverage is 69.76%. Comparing base (99998b8) to head (0789d24).
Report is 60 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
...hicle_position/VehiclePositionUpdaterRunnable.java	0.00%	12 Missing ⚠️
...planner/updater/configure/UpdaterConfigurator.java	16.66%	8 Missing and 2 partials ⚠️
...opentripplanner/ext/siri/SiriFuzzyTripMatcher.java	61.11%	4 Missing and 3 partials ⚠️
...ehicle_position/PollingVehiclePositionUpdater.java	0.00%	5 Missing ⚠️
...ner/ext/siri/updater/azure/SiriAzureETUpdater.java	0.00%	4 Missing ⚠️
...pentripplanner/ext/siri/updater/SiriETUpdater.java	0.00%	3 Missing ⚠️
...pentripplanner/ext/siri/updater/SiriSXUpdater.java	0.00%	3 Missing ⚠️
...t/siri/updater/azure/AbstractAzureSiriUpdater.java	0.00%	3 Missing ⚠️
...ner/ext/siri/updater/azure/SiriAzureSXUpdater.java	0.00%	3 Missing ⚠️
...anner/updater/alert/GtfsRealtimeAlertsUpdater.java	0.00%	3 Missing ⚠️
... and 9 more

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6029      +/-   ##
=============================================
+ Coverage      69.73%   69.76%   +0.03%     
- Complexity     17315    17327      +12     
=============================================
  Files           1960     1961       +1     
  Lines          74267    74267              
  Branches        7603     7603              
=============================================
+ Hits           51789    51812      +23     
+ Misses         19834    19813      -21     
+ Partials        2644     2642       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[abyrd]

Thanks for the very clear PR description and Javadoc on the interface. This looks like a good step in the right direction.

If I am seeing correctly, the same DefaultRealTimeUpdateContext instance is used for all successive updates, across all successive snapshots (a new instance is not made for each snapshot). This instance is in some sense the outer unifying layer of the persistent buffer from which we take snapshots. The lifecycle (specifically the long duration) of these instances might be worth mentioning in the Javadoc of the implementation classes.

[abyrd]

For future reference: As discussed in a recent meeting, it's not clear that in the long term we actually want the updaters to consult changes introduced by previously applied update messages, including changes introduced within the same batch of updates between two snapshot publications. We may want updates to be idempotent and interpreted independent of one another, to the greatest extent possible. For example, the choice between creating a realtime-added trip or pattern and reusing an already created one could be encapsulated within a method exposed to the updaters by a deeper layer of the system, so the updaters don't need to know whether another update already created that trip or pattern. But the current system relies on updaters performing their own lookups to function, and these PRs serve to clean up that existing system in advance of any more extensive overhaul to the design.

[t2gran]

Just one minor formatting of a comment...

[t2gran]

@abyrd already approved this and the only change after that was a small change to a JavaDoc format, so I will merge this without waiting for a formal last approval from @abyrd.