Map GTFS notice assignments on trip segments to individual stop times

[leonardehrenfried]

Summary

Adds support for GTFS notice_assignments.txt entries that target trip_segments. A trip segment (a [from_stop_sequence, to_stop_sequence] range on a trip) is now expanded so that the referenced notice is attached to every stop time the segment covers, instead of being ignored.

Issue

This builds on #7801, which added the trip_segments table to the GTFS parser but ignored it when mapping notices (the trip_segments case previously returned null). Trip segments are part of the experimental GTFS proposal google/transit#638.

How the code works:

• A new TripSegmentMapper resolves each trip_segment_id to the StopTimeKeys of the stops within the segment's range. It uses the trip's sequence-ordered stop times (TripStopTimes) and includes every stop time whose GTFS stop_sequence falls within [from_stop_sequence, to_stop_sequence].
• The StopTimeKey is built from the 0-based stop position in the pattern, not the raw GTFS stop_sequence, to match how StopTimeKeys are referenced elsewhere in OTP. The StopTimeKey.of(...) Javadoc was clarified accordingly.
• The mapped keys are stored by trip_segment_id, and NoticeAssignmentMapper looks them up when resolving assignments, emitting one notice assignment per covered stop time. Assignments referencing an unknown record continue to be reported as data-import issues.

Unit tests

Unit tests were added to NoticeAssignmentMapperTest covering trip-segment notice assignments:

• a multi-stop segment range that resolves to several stop times,
• a single-stop segment (from_stop_sequence == to_stop_sequence),
• verification that the stop's position in the pattern, rather than the GTFS stop_sequence, is used to build the key (using non-contiguous stop sequences).

The mapping logic is tested at the mapper level with no need for a full graph build.

Documentation

• Added Javadoc to TripSegmentMapper describing its purpose and the stored result.
• Clarified the StopTimeKey.of(...) parameter documentation to state that the position is the 0-based stop position in the pattern rather than the GTFS stop_sequence.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.25%. Comparing base (a06a51e) to head (ca37260).
⚠️ Report is 45 commits behind head on dev-2.x.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #7809      +/-   ##
=============================================
+ Coverage      74.23%   74.25%   +0.01%     
- Complexity     22154    22169      +15     
=============================================
  Files           2461     2462       +1     
  Lines          86648    86675      +27     
  Branches        8574     8578       +4     
=============================================
+ Hits           64325    64358      +33     
+ Misses         19285    19283       -2     
+ Partials        3038     3034       -4     

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MaxGosau]

good addition, implementation looks clean.