core: remove the middle green signals in the STD

[Khoyo]

Currently, VL (green) blocks only have a meaning before the train, and the meaning is "I require this signal to be open to keep to my schedule".
After/during the train, the meaning would be "I don't constrain this signal" which is actually what blank means. So let's keep those cases blank.

Case appears when diverging from the projected path, stopping on closed signal, then converging (stop in the same station, but different track)
Before:

After this PR:

Relates to 1 part of https://github.com/osrd-project/osrd-confidential/issues/886

[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 38.17%. Comparing base (782fe85) to head (1d3b9f7).
Report is 5 commits behind head on dev.

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

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #9906      +/-   ##
==========================================
- Coverage   38.20%   38.17%   -0.03%     
==========================================
  Files         998      998              
  Lines       92193    92197       +4     
  Branches     1192     1192              
==========================================
- Hits        35220    35200      -20     
- Misses      56517    56541      +24     
  Partials      456      456              

Flag	Coverage Δ
editoast	73.32% <ø> (-0.07%)	⬇️
front	20.16% <ø> (-0.01%)	⬇️
gateway	2.18% <ø> (ø)
osrdyne	3.28% <ø> (ø)
railjson_generator	87.49% <ø> (ø)
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.

[bougue-pe]

(completed the main description)

It doesn't work from my test.
Maybe be should also shorten the first free block? 🤔

[Khoyo]

(completed the main description)

It doesn't work from my test. Maybe be should also shorten the first free block? 🤔

Nah, we should do it in the right file.

So... I also removed the old signal projection logic and adapted the v1 signal projection endpoint

[bougue-pe]

I'm not sure I understand what you did on the SignalProjectionEndpoint (v1): why can't we completely remove it?
If we keep it like this, we probably need a clear todo to accelerate future cleanup work.

[bougue-pe]

Shouldn't we put it in a kt dir?
Or should we just not care and add a deprecated comment right away?

[Khoyo]

The kotlin directory is not necessary anymore since at least Kotlin 1.0. I believe we should probably just merge the kotlin and java dirs

[Erashin]

Hmm. Personal opinion: I'd rather not merge the directories, since the end goal is probably just to have the whole thing in kotlin, it makes a clear distinction between what we have to keep and what we have to migrate.
For that reason as well, as long as we separate them, I'd rather have the kotlin files in the kotlin directory (especially since it already exists).

[Khoyo]

I'd rather not merge the directories, since the end goal is probably just to have the whole thing in kotlin, it makes a clear distinction between what we have to keep and what we have to migrate.

I really don't get that. If it's about the kotlin/java migration, just find -name '*.java'?

If it's about the obsolete v1 APIs, this is an obsolete v1 api file :p

This is working now (even though there are other questions).

[Khoyo]

I'm not sure I understand what you did on the SignalProjectionEndpoint (v1): why can't we completely remove it?

We're keeping the TSv1 endpoints for a few more months (I believe until some time in January). But there is not reason to keep the old logic if we can avoid it.

[Erashin]

This looks like it's working as intended.
Give me your opinion on the kotlin/java module question.
I'd love a unit test on this case as well.

[Erashin]

Hmm. Personal opinion: I'd rather not merge the directories, since the end goal is probably just to have the whole thing in kotlin, it makes a clear distinction between what we have to keep and what we have to migrate.
For that reason as well, as long as we separate them, I'd rather have the kotlin files in the kotlin directory (especially since it already exists).