Cleanup regular transfer build parameters

[t2gran]

Summary

This is a pure refactoring of the transfer-related build configuration parameters. Three previously separate build config concerns — maxTransferDuration, transferRequests, and transferParametersForMode — are grouped into a single RegularTransferParameters value object, making the API surface of BuildConfig and DirectTransferGenerator cleaner and cohesive. No behavioral changes are introduced.

This PR does not change the configuration. A similar refactoring to group transfer parameters in the configuration is welcome, but I will not do for now.

I have used the new name RegularTransfer, and not the old DirectTransfer for everything I have changed. A refactoring to change DirectTransfer to RegularTransfer would be nice, but that is a large refactoring.

Refactoring

New parameters class: RegularTransferParameters

A new immutable value object RegularTransferParameters (with a Builder) groups the three related transfer build parameters:

• maxDuration (formerly maxTransferDuration on BuildConfig)
• parametersForMode (formerly transferParametersForMode on BuildConfig)
• requests (formerly transferRequests on BuildConfig)

BuildConfig now exposes a single regularTransferParameters() accessor instead of three public fields, improving encapsulation.

Renamed and relocated types

Before	After
graph_builder/module/TransferParameters	graph_builder/module/transfer/api/TransferParametersForMode
config/buildconfig/TransferParametersMapper	config/buildconfig/RegularTransferConfig
config/buildconfig/TransferConfig	(merged into RegularTransferConfig)
config/buildconfig/TransferRequestConfig	(merged into RegularTransferConfig)

The new names better reflect their roles:

• TransferParametersForMode clarifies that this holds per-mode parameters (not all transfer parameters).
• RegularTransferConfig consolidates all regular-transfer JSON config mapping in one place.

Simplified DirectTransferGenerator constructor

The constructor previously accepted three separate parameters (Duration, List<RouteRequest>, Map<StreetMode, TransferParameters>). It now accepts a single RegularTransferParameters instance, reducing call sites from 3 arguments to 1.

Testing

Unit Tests

• ✅ Existing tests updated to use the parameters class
• 🟥 No new tests needed — this is a rename/consolidation refactor with no behavior changes

Documentation

• ✅ Code follows OTP style guidelines (Prettier, JavaDoc)
• ✅ JavaDoc preserved/updated for renamed types
• ✅ No configuration option changes — only internal restructuring of how config is parsed

Changelog

• 🟥 No changelog entry needed — this is an internal refactoring with no user-visible changes.

Bumping the serialization version id

• 🟥 No serialized classes changed.

[codecov]

Codecov Report

❌ Patch coverage is 95.19231% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.29%. Comparing base (13403b0) to head (4987f88).
⚠️ Report is 144 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
..._builder/module/configure/GraphBuilderModules.java	0.00%	2 Missing ⚠️
...entripplanner/routing/via/configure/ViaModule.java	0.00%	1 Missing ⚠️
...opentripplanner/standalone/config/BuildConfig.java	50.00%	1 Missing ⚠️
...lone/config/buildconfig/RegularTransferConfig.java	96.55%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #7425      +/-   ##
=============================================
+ Coverage      71.12%   71.29%   +0.16%     
- Complexity     20895    20971      +76     
=============================================
  Files           2332     2332              
  Lines          86631    86710      +79     
  Branches        8579     8581       +2     
=============================================
+ Hits           61615    61818     +203     
+ Misses         22038    21897     -141     
- Partials        2978     2995      +17     

☔ 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]

There is a tiny typo, but this looks like a good simplification.

[VillePihlava]

Looks good, I just found a naming issue

[VillePihlava]

Although I think the renaming to e.g. maxDuration makes sense, now there is a discrepancy between the names in TransferParametersForMode, i.e.

maxTransferDuration
carsAllowedStopMaxTransferDuration
bikesAllowedStopMaxTransferDuration

I think for the sake of clarity, maybe we should leave the word transfer in the names. What do you think? Also its possible that someone adds a maximum duration to the transfer config that isn't the maximum transfer duration.

[t2gran]

I think we should rename the names in TransferParametersForMode and follow defacto OOP naming conventions. I can do that in this PR if you want.

[VillePihlava]

I would want them to be consistent, but I would prefer leaving the transfer as part of the name. For example, carsAllowedStopMaxTransferDuration is clearer than carsAllowedStopMaxDuration, or disableDefaultTransfers is clearer than disableDefaults.

This is not that important for me so we can also just leave them as is, or you can name them to what suits you

[t2gran]

Please don´t do that. We use OOP and it should be DRY (Contextual Naming). This apply to APIs as well. If the context is not clear, you may consider repeating it or if something could exist outside the context.