core: update start of free block in signal projection (space-time chart) when stopping on closed signal

[bougue-pe]

Fix #8814

This is done by amending signal-sightings with stop-ending (minus margin) when stop is on closed signal

Also:

• Adds corresponding integration test

A complete comment up-to-date is also worth reading: #9661 (comment)

🔍 review by commit is probably easier

[codecov-commenter]

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

Codecov Report

Attention: Patch coverage is 88.88889% with 3 lines in your changes missing coverage. Please review.

Project coverage is 38.21%. Comparing base (b4a69f6) to head (08755cd).
Report is 88 commits behind head on dev.

Files with missing lines	Patch %	Lines
editoast/src/views/train_schedule/projection.rs	0.00%	3 Missing ⚠️

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

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #9661      +/-   ##
==========================================
+ Coverage   37.88%   38.21%   +0.33%     
==========================================
  Files         992      995       +3     
  Lines       90966    91909     +943     
  Branches     1176     1189      +13     
==========================================
+ Hits        34463    35124     +661     
- Misses      56049    56331     +282     
  Partials      454      454              

Flag	Coverage Δ
editoast	73.27% <40.00%> (-0.10%)	⬇️
front	20.23% <ø> (+0.11%)	⬆️
gateway	2.18% <ø> (ø)
osrdyne	3.28% <ø> (ø)
railjson_generator	87.49% <ø> (ø)
tests	87.00% <100.00%> (+0.25%)	⬆️

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.

[emersion]

LGTM for the frontend (not tested)

[woshilapin]

Nice improvement, and less dead code if I understand correctly. Also, you will need to rebase because a CI PR happened in between which explains why you see 50 steps (instead of 25) with half of them not running.

[Khoyo]

(I don't see the dead code removal :p)

I believe we need signal sightings in order to only output green zones for signal that are effectively constraining the projected train. path_signals are about the path that's projected onto, and requirements are zone based, so we cannot only rely on those.

Here is an example:

The first green block in this image should not be there, as the first train never sees that signal

[bougue-pe]

All rewritten, as discussed with @Khoyo:
Space-requirements start are not displayed in space-time chart, what's displayed for free block is the first moment where a signal must be free (usually signal sighting by the train, or the stop ending when on closed signal).
So:

• back to using "signal-sighting" (amended with closed stop positions)
• little refactors on the way (🔍 review by commit)
• ✅ hand-tested that @Khoyo's example is now OK
  
• ✅ hand-tested that it works as expected
  
• previous work is stored in branch https://github.com/OpenRailAssociation/osrd/tree/peb/core/use_spacing_reqs_for_free_block_in_space_time_chart

[Khoyo]

Nicely done 👍🏻

[woshilapin]

Is signal_critical_position better than signal_sighting? I'm sure I don't understand all of it, but intuitively, "signal sighting" means something in my mind (when you see the signal), whereas "signal critical position" feels like it's missing some context: critical for what (or for when)? Feel free to disregard if this is about a shared jargon term.

[shenriotpro]

Thanks