Simplify fetching entire trip from an estimatedCall

[lassetyr]

We frequently get questions on how the fetch the rest of the trip - for the correct date - on e.g. departure-board-queries.

This PR adds the possibility to fetch this more easily.

[codecov]

Codecov Report

❌ Patch coverage is 58.33333% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.97%. Comparing base (b5f5faf) to head (8674d82).
⚠️ Report is 7 commits behind head on dev-2.x.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...is/transmodel/model/siri/et/EstimatedCallType.java	58.33%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             dev-2.x    #6811   +/-   ##
==========================================
  Coverage      71.96%   71.97%           
- Complexity     19423    19426    +3     
==========================================
  Files           2099     2099           
  Lines          78756    78769   +13     
  Branches        7970     7970           
==========================================
+ Hits           56680    56697   +17     
- Misses         19257    19258    +1     
+ Partials        2819     2814    -5     

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

Would it not make sense to return the ServiceJourney on a specific day? I see that you already have a field for the DatedServiceJourney which does something similar.

(I don't know if you already have a type for this in the schema...)

[lassetyr]

I chose to add this as serviceJourneyEstimatedCalls because a field with the same name, type and functionality already exists in leg for a similar purpose.
(https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/application/src/main/resources/org/opentripplanner/apis/transmodel/schema.graphql#L388)

For a ServiceJourney on a specific day, the only part that is dependent on the operating-date will be the estimatedCalls-part.

[t2gran]

I would like to see something like this:

serviceJourneyEstimatedCalls : SJEstimatedCalls!

type SJEstimatedCalls {
  first : EstimatedCall
  last : EstimatedCall
  next(antall : Int) : [EstimatedCall!]!
  previous(antall : Int) : [EstimatedCall!]!
}

[t2gran]

We are rethinking this. An issue is on its way.