editoast: refactor of projection algorithm

[woshilapin]

fixes #9686

This is a complete rewrite of the projection algorithm. The idea is to support the case when multiple track ranges with the same track section identifier are projected on an axis. PathProjection can't support that use case since the constructor assert for no duplicate identifiers.

In order to minimize the modifications, we decided to not change the constructor of PathProjection. The important change is the inversion of the semantic for the function get_intersection(): before, self was projected on track_ranges, now, we project track_ranges on self. Since we will always project on a continuous path, we can then keep the constructor of PathProjection with it assertions about no duplicate identifiers.

Warning

There is still a bunch of things to do.

• must be merged after editoast: improve tests for projection #10137
• all callers of PathProjection::get_intersection() needs to be inverted (remember, now, track_ranges is projected on path, not the other way around)
• a reminding problem about intersections that are merged and shouldn't be merged (see below)
• minor: do we want to keep the custom implementation of Debug for TrackRange (or maybe it should be a Display implementation instead?)

The ones that shouldn't be merged

When you have a projection path A+0-100, B+0-100 and you want to project the following track ranges on it, A+0-150 and B+0-100, the result should be 2 intersections, (0, 100) and (100, 200) and you don't want to merge them (or do we?). Indeed, the train path you're trying to project is moving in space but also in time on A+100-150 which means that between A+100 and B+0, there will be a hole in the Space-Time Chart.

An attempt to solve this problem has been done by introducing the is_exhaustive in the TrackRangeEvent: the idea is to keep the information that the overlap is exhaustive on the track range being projected, or not. It does work for Begin where it can be used... but I didn't find an obvious way to use the is_exhaustive from End 🤷

Unsolved questions about this merge strategy

• Should we actually not merge them? The idea makes sense if you're trying to project a train path, but does it still make sense for a work schedule which doesn't move in space or time.
• Could we always merge (would simplify the algorithm) and separate later in the post-processing (trying to get the time of these locations) ?
• 💡Maybe we don’t want to merge anything at all? The impact would be producing more payload (is that really that much), but it would probably drastically simplify the algorithm (that would mean that there would be at least one intersection per track section).

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.70%. Comparing base (3bc6d02) to head (67ff663).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev   #10164      +/-   ##
==========================================
+ Coverage   79.94%   81.70%   +1.75%     
==========================================
  Files        1057      778     -279     
  Lines      106302    76219   -30083     
  Branches      724      724              
==========================================
- Hits        84980    62272   -22708     
+ Misses      21280    13905    -7375     
  Partials       42       42              

Flag	Coverage Δ
editoast	?
front	89.19% <ø> (ø)
gateway	2.18% <ø> (ø)
osrdyne	3.28% <ø> (ø)
railjson_generator	87.50% <ø> (ø)
tests	87.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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