core: pathfinding: filter out paths with repeated tracks during exploration

[eckter]

Prevents issues where the post-processing fails because of "repeated tracks in the path".

The result changes to "no path found" in most cases, but this time with some more details (such as constraints). It finds some new paths, but they make some extreme detours.

It does come with a mild performance hit (roughly +10% computation time).

[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 79.85%. Comparing base (419a315) to head (7fe53c5).
Report is 17 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    #9971      +/-   ##
==========================================
- Coverage   79.85%   79.85%   -0.01%     
==========================================
  Files        1048     1048              
  Lines      105046   105086      +40     
  Branches      756      756              
==========================================
+ Hits        83883    83913      +30     
- Misses      21122    21132      +10     
  Partials       41       41              

Flag	Coverage Δ
editoast	73.37% <ø> (-0.02%)	⬇️
front	89.34% <ø> (+<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.

[Khoyo]

LGTM, although I'm not sure I'd call a 10% hit mild...

I also wonder if we could do something about it, eg. paying copies vs traversing a linked list or better tuning of the bloom filter

[eckter]

I also wonder if we could do something about it, eg. paying copies vs traversing a linked list or better tuning of the bloom filter

I already did and tried some optimizations, in the current version almost all of the extra computing time is spent actually creating the linked list itself. I don't know if that could be avoided.

I can think of some vague idea about using bitsets the size of the number of tracks in the infra, and marking them that way. But it would be quite tricky. edit: wait no that sounds bad