Fix SIRI update travel back in time

[vpaturet]

Summary

As detailed in #5866, some combinations of SIRI messages lead to the creation of invalid trips where passing times do not increase along the journey.
This PR aims to fix one such scenario where:

1. a first SIRI message creates an extra journey with invalid scheduled data and valid real time data.
2. OTP accepts the real time data without validating the scheduled data.
3. a second message cancels the extra journey.
4. OTP accepts the cancellation, delete the real time data and falls back to the (invalid) scheduled data.

The canceled trip can then be queried thanks to the API parameter includeRealtimeCancellations=true

The proposed fix is to validate the scheduled data in step 2 and rejects messages that contain invalid scheduled data.

Issue

Closes #5866

Unit tests

Added unit test

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.47%. Comparing base (06a7e8c) to head (e7e38e4).
Report is 1 commits behind head on dev-2.x.

❗ Current head e7e38e4 differs from pull request most recent head d84e7f5

Please upload reports for the commit d84e7f5 to get more accurate results.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5867      +/-   ##
=============================================
- Coverage      68.54%   68.47%   -0.07%     
+ Complexity     16732    16699      -33     
=============================================
  Files           1918     1914       -4     
  Lines          72734    72676      -58     
  Branches        7456     7454       -2     
=============================================
- Hits           49854    49768      -86     
- Misses         20310    20338      +28     
  Partials        2570     2570              

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

[vpaturet]

@lassetyr The fix introduces a systematic validation of scheduled data for extra journeys:
a71c690
(there is only one commit in this PR, it should be rebased when #5865 is merged)

This is likely to have little impact on performance, but may lead to more rejected messages. Is this acceptable?

[lassetyr]

I do not see any reason why we/OTP should accept invalid data, so in my opinion, this is acceptable.

[t2gran]

The code looks ok, just a few questions.