Add validation of NeTEX timetabled passing times

[vpaturet]

Summary

As detailed in #5060, OTP fails to filter NeTEx ServiceJourneys with incorrect passing times: validation errors are reported in the HTML validation report, but incorrect data are not removed from the graph.

In the current NeTEx import implementation, the validation, performed in ValidateAndInterpolateStopTimesForEachTrip.run(), occurs too late in the import workflow, after the ServiceJourneys have been mapped to TripTimes.
In the GTFS import case, ValidateAndInterpolateStopTimesForEachTrip is called early enough and invalid data are properly filtered out.

The design solution followed in this PR is to leverage the NeTEx validator framework (org.opentripplanner.netex.validation.Validator) and implement a custom validation rule for NeTEx passing times.
The benefits of this approach over using ValidateAndInterpolateStopTimesForEachTrip are:

• it is in line with the error handling approach used throughout the NeTEx import, which is to filter out and report broken data without trying to fix it.
• it takes into account the specificities of the NeTEx format, in particular the relation between ServiceJourney and JourneyPattern, and the data structures in NeTEx-flex.
• it provides more specific error messages that makes debugging/analysis easier.

The validation rule covers all 4 combinations of stop sequences:

• regular stop followed by regular stop
• area stop followed by area stop
• regular stop followed by area stop
• area stop followed by regular stop

The call to ValidateAndInterpolateStopTimesForEachTrip.run() is kept unchanged for now, as it provides also side-effect-free validation for hop speed and hop time.
A refactoring can be performed in a subsequent PR for splitting ValidateAndInterpolateStopTimesForEachTrip in two classes: one class, used only in the GTFS import, that would fix/interpolate passing times, and another that would report suspicious hop time/hop distance.

Tested on the all-Norway and all-Sweden NeTEx datasets.

Issue

closes #5060

Unit tests

Added unit tests

[codecov]

Codecov Report

Patch coverage: 86.84% and project coverage change: +0.27 🎉

Comparison is base (b9f4016) 64.57% compared to head (087f866) 64.85%.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5081      +/-   ##
=============================================
+ Coverage      64.57%   64.85%   +0.27%     
- Complexity     13889    14231     +342     
=============================================
  Files           1715     1740      +25     
  Lines          67112    67644     +532     
  Branches        7207     7239      +32     
=============================================
+ Hits           43338    43868     +530     
+ Misses         21348    21339       -9     
- Partials        2426     2437      +11     

Impacted Files	Coverage Δ
...opentripplanner/netex/mapping/StopTimesMapper.java	67.77% <ø> (ø)
...er/netex/support/stoptime/AreaStopTimeAdaptor.java	60.00% <60.00%> (ø)
...netex/index/hierarchy/AbstractHierarchicalMap.java	87.87% <66.66%> (-12.13%)	⬇️
...netex/support/stoptime/RegularStopTimeAdaptor.java	80.00% <80.00%> (ø)
...dation/ServiceJourneyNonIncreasingPassingTime.java	82.85% <82.85%> (ø)
...etex/support/stoptime/AbstractStopTimeAdaptor.java	86.95% <86.95%> (ø)
...ripplanner/netex/support/ServiceJourneyHelper.java	100.00% <100.00%> (ø)
...ntripplanner/netex/support/ServiceJourneyInfo.java	100.00% <100.00%> (ø)
...lanner/netex/support/stoptime/StopTimeAdaptor.java	100.00% <100.00%> (ø)
...r/netex/validation/AbstractHMapValidationRule.java	100.00% <100.00%> (ø)
... and 1 more

... and 169 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[leonardehrenfried]

Would I make sense to create a wrapper class for for TimetabledPassingTime, which would be similar to CallWrapper for Siri or indeed ServiceJourneyInfo?

That means you can move these helper method in there.

[t2gran]

If you do, please use the Adaptor design pattern and naming convention. CallAdaptor not CallWrapper,
Ref: https://refactoring.guru/design-patterns/adapter

[vpaturet]

Refactored

[vpaturet]

I thought about calling it Adapter, but this is not strictly an implementation of the design pattern (no interface involved, just composition)

[leonardehrenfried]

I like the architecture but I don't know a lot about the domain we are validating here.

[vpaturet]

@leonardehrenfried could you please review again? There is no need to rebase, this PR contains both commits from Thomas and me (which makes the reviewing process more complicated actually).
I reviewed the commits from Thomas and I am OK with them.