editoast, schemas: add 'freight_compatible' to the rolling stock model

[woshilapin]

Classify rolling stock between those that can be used as fret, and those who don't (or those we don't know). A new field freight_compatible is added to the rolling stock schema (both python osrd_schemas and editoast), then also to the rolling stock model (DB), and finally in all API exposed struct like LightRollingStock and RollingStockForm.

Since there is still a lot of rolling stock for which we don't know any information, the new field is nullable.

⚠️ First thing to review: what do you think of the naming freight_compatible. If you don't like it, have other ideas, don't spend time reviewing the rest of the PR, let's discuss that first.

I also added a little icon for freight compatible train in the rolling stock editor.

[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 87.49%. Comparing base (68e0513) to head (78b1852).
Report is 6 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    #8856       +/-   ##
=============================================
+ Coverage     37.13%   87.49%   +50.35%     
=============================================
  Files          1260       31     -1229     
  Lines        115076     1535   -113541     
  Branches       3230        0     -3230     
=============================================
- Hits          42736     1343    -41393     
+ Misses        70407      192    -70215     
+ Partials       1933        0     -1933     

Flag	Coverage Δ
core	?
editoast	?
front	?
gateway	?
osrdyne	?
railjson_generator	87.49% <ø> (ø)
tests	?

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.

[leovalais]

LGTM. I'm fine with freight_compatible. About its nullability: do we plan to make the field non-nullable eventually or is there a benefit to encode "we're not sure" in the application?

[flomonster]

I would have preferred an enum field like transport_type.

With these possible values:

• freight
• passenger
• construction for stuff like tamping machines
• ...

[woshilapin]

I would have preferred an enum field like transport_type.

With these possible values:

* `freight`

* `passenger`

* `construction` for stuff like [tamping machines](https://en.wikipedia.org/wiki/Tamping_machine)

* ...

@flomonster I see, but I don't think that is ok, because it's not an XOR. A locomotive can be both freight and passenger compatible. A better modeling would be some sort of list of tags... but that might mean another DB table and maybe a bit more design. What do you think?

[shenriotpro]

Thanks

[flomonster]

I see, but I don't think that is ok, because it's not an XOR. A locomotive can be both freight and passenger compatible. A better modeling would be some sort of list of tags... but that might mean another DB table and maybe a bit more design. What do you think?

I see, why do we need this information attached to the rolling stock? Is it only for the icon?

[woshilapin]

I see, why do we need this information attached to the rolling stock? Is it only for the icon?

@flomonster No, we're going to use it to filter what is presented in the STDCM form, see #8921 for the following PR. The icon was just a quick win to display this information somewhere.

[flomonster]

I see, why do we need this information attached to the rolling stock? Is it only for the icon?

No, we're going to use it to filter what is presented in the STDCM form, see #8921 for the following PR. The icon was just a quick win to display this information somewhere.

I think the best way to deal with this in the long term is to have groups of rolling stock (necessary for permissions). Then we could assign a group of rolling stock to the STDCM search environment.

It feels weird to add a flaky field and limit usage of STDCM depending of this field.

Note

Since we want this feature quickly and we can't wait for rolling stock groups, should we add an hotfix in the frontend? It seems easier to revert than changing our model.

[woshilapin]

LGTM. I'm fine with freight_compatible. About its nullability: do we plan to make the field non-nullable eventually or is there a benefit to encode "we're not sure" in the application?

@leovalais I actually went back and forth on this idea, first thinking, if we don't know, we just don't know, it's not necessary false. But then I realize that on STDCM form, we're going to have to take a decision about "do we display rolling stocks that are null or not?" and the answer is not clear. So I made the change to simplify the code in 78b1852.

[clarani]

LGTM for the front part ✅

[woshilapin]

Finally closing this PR. After discussion with multiple actors (@clarani @flomonster @axrolld), we realized that the vision is not yet clear and that we can achieve our short-term objective differently: we can have much less technical debt by encoding what we need directly in front without modifying our internal backend model.