Add support for DSJ in transit leg reference

[vpaturet]

Summary

As detailed in #5422, a transit leg reference should refer to a TripOnServiceDate id (i.e. dated service journey id) when one exists,
since a dated service journey provides a more stable id across deliveries of planned data.

The PR introduces also a builder for ScheduledTransitLeg and FrequencyTransitLeg.

Issue

Closes #5422

Unit tests

Added unit tests

Documentation

No

[codecov]

Codecov Report

Attention: 36 lines in your changes are missing coverage. Please review.

Comparison is base (8394b7c) 66.82% compared to head (07ec689) 66.88%.
Report is 6 commits behind head on dev-2.x.

❗ Current head 07ec689 differs from pull request most recent head ef5f54c. Consider uploading reports for the commit ef5f54c to get more accurate results

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5455      +/-   ##
=============================================
+ Coverage      66.82%   66.88%   +0.06%     
- Complexity     15473    15517      +44     
=============================================
  Files           1798     1800       +2     
  Lines          69804    69906     +102     
  Branches        7359     7361       +2     
=============================================
+ Hits           46646    46758     +112     
+ Misses         20702    20692      -10     
  Partials        2456     2456              

Files	Coverage Δ
...tripplanner/ext/fares/impl/DefaultFareService.java	94.44% <100.00%> (+2.21%)	⬆️
...pplanner/ext/fares/model/FareAttributeBuilder.java	72.41% <ø> (-0.76%)	⬇️
...planner/ext/realtimeresolver/RealtimeResolver.java	83.87% <100.00%> (-2.98%)	⬇️
...ntripplanner/gtfs/mapping/FareAttributeMapper.java	95.00% <100.00%> (ø)
...planner/model/plan/ScheduledTransitLegBuilder.java	100.00% <100.00%> (ø)
...nner/model/plan/legreference/LegReferenceType.java	89.47% <100.00%> (+0.58%)	⬆️
...lan/legreference/ScheduledTransitLegReference.java	86.58% <100.00%> (+4.91%)	⬆️
...anner/routing/alternativelegs/AlternativeLegs.java	92.17% <100.00%> (+0.99%)	⬆️
...opentripplanner/ext/fares/impl/HSLFareService.java	68.26% <50.00%> (ø)
...opentripplanner/ext/fares/model/FareAttribute.java	57.14% <50.00%> (-0.76%)	⬇️
... and 7 more

... and 8 files with indirect coverage changes

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

[vpaturet]

This implementation guarantees backward compatibility (newer versions of OTP can parse tokens generated by previous versions of OTP), but not forward compatibility (an older version of OTP would fail when attempting to deserialize a token generated by a newer version). This is due to the deserializer attempting to resolve the token version as a Java enum, which is missing in older versions of the class.
This issue may arise when running a rolling update in a cloud environment, where both the old and new version of OTP are running simultaneously during a short period.
However, while testing in a production-like environment, the error did not occur: leg references are most likely used over longer periods than a typical rollout time (in other words: the leg reference is queried long enough after the token was created).

The conclusion is that:

• forward compatibility is a minor, non-blocking issue in regard to the more serious consistency issues that this PR intends to fix.
• the versioning mechanism should be revisited as suggested in Create a reusable token generator #5451

[leonardehrenfried]

Nice.