Core: refactor SpeedLimit handling from infra to respect specification

[bougue-pe]

As commented in a core TODO, internal model for SpeedLimit isn't able to handle a speed-limit acting only on a train using a specific route and a specific speedLimitTag (and not acting on train using the same route with another speedLimitTag, or the same speedLimitTag but another route).

Yet, this is specified to be possible in speed limit data model specification.

The goal of this ticket is to refactor core's internal model, parse, merge and use to make it possible.

⚠ Notes:

• dags may have to be updated too
• speed-limits by signaling system may be added by https://github.com/osrd-project/osrd-confidential/issues/609: better be robust already

AC:

• [ ] a proper integration test is necessary to make sure that all the back part is OK and editoast doesn't "protect" current core's limitation. So circulating on a given track-section :
  • [ ] check that a speedLimit affecting a route AND a tag is affecting train with proper route and tag
  • [ ] check that a train with the same tag but different route is not affected by the limit
  • [ ] check that a train on the same route but different tag is not affected
  • [ ] check that "regular" speed-limits (no tag or route, only a tag, only a route) are still working
  • [ ] check that dags produces correct data considering the change introduced

[flomonster]

Is it a bug or simply a code refactoring task?

[bougue-pe]

It's borderline as it doesn't fulfill the specifications from the website it may be considered a bug... But as it is triggered by a tech retro-engineering and not a functional test, it may be considered a refactor only (or at least lower the priority of the bug). So either one is fine by me.

[Tguisnet]

Still present, @Castavo want to discuss it

[bougue-pe]

Permanent speed-limits (LPV) and temporary ones (LTV) require this fix, as detected by operational study users.

This needs a little check to see if an editoast infra error is attached to that current case (as it's incompatible with core it may be protected), so a proper integration test is required on that.

[bougue-pe]

Postponed for PI 13 as it shouldn't block anything. Also, it would be nice to know for sure what is required for signaling-system speed-limits: very likely to be the same as for speed-limit-tags or route (be able to apply a speed-limit only to trains with a given tag and route and signaling system).