Remove deprecated relaxTransitSearchGeneralizedCostAtDestination

[t2gran]

Summary

This PR removes the relaxTransitSearchGeneralizedCostAtDestination input field in the trip plan request in the Transmodel API.

This feature was an experiment and should not have been used in production. It was deprecated in 2023-12-20. We take away the parameter from the API now, and then if noone complains, then we will remove the feature implementation
including Raptor code in a few weeks time.

I have not removed the implementation or the configuration for this - we are waiting to see if this will cause any problems. But, I will remove all code for this feature before I continue with the via Raptor improvements. There is a bit of work and risk when removing this, so we prefer to do it in 2 steps.

Issue

🟥 There is not issue for this.

Unit tests

✅ The API schema test is updated.

Documentation

✅ Doc on the feature is removed

Changelog

🟥 This feature was hopefully only used at Entur - it never worked in a good way. We do not need this in the change log.

Bumping the serialization version id

🟥 Not needed

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.24%. Comparing base (52dc65f) to head (8f50ca9).
Report is 168 commits behind head on dev-2.x.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6540      +/-   ##
=============================================
- Coverage      70.24%   70.24%   -0.01%     
- Complexity     18369    18370       +1     
=============================================
  Files           2087     2087              
  Lines          77381    77372       -9     
  Branches        7839     7839              
=============================================
- Hits           54357    54348       -9     
  Misses         20249    20249              
  Partials        2775     2775              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[leonardehrenfried]

You know the consequences, so you have my approval.

[miklcct]

What will happen if people continue to send this field on the API? Don't we have a policy that we shouldn't break compatibility at the API level?

[habrahamsson-skanetrafiken]

We aren't using this parameter at skånetrafiken, so it shouldn't cause any issues for us really.

But as @miklcct points out this does go against our decision records.

If we want to be able to do backwards incompatible changes I think we should have an explicit deprecation policy so that our users knows what they can expect. For example we could say that we keep deprecated fields for at least 4 releases, or we could have a specific policy for experimental fields. Currently we are implying that we will never break compatability.

What do you think about that @t2gran ?

[t2gran]

In general I agree that we should not break backwards compatibility:

• But this feature did never work properly - it has severe unlogical side-effects, it was an experiment from the start.
• I want it to break, so we can work with potensial users to migrate to the right way of doing this.
• If someone show up and say they use this, then I will add the parameter back. (Just the parameter, not the implementation).

We should probably discuss how we want to cleanup on the API:

1. A policy that 2 years old fields can be removed?
2. Make regular major releases every 2 years and remove all deprecated field older than 1 year.

For the policy in our decision records I think we should clarify that some feature might be unstable during development. These features/parameters should be clearly documented.

[leonardehrenfried]

We should probably discuss how we want to cleanup on the API:

1. A policy that 2 years old fields can be removed? 
2. Make regular major releases every 2 years and remove all deprecated field older than 1 year.

We should discuss the specifics but I agree with the idea that we can correct mistakes and carefully remove parts of the API that have been deprecated and had a replacement for many years.