Inject defaults into the planConnection query in the GTFS GraphQL schema

[optionsome]

Summary

Inject defaults (either from code or configuration) into the planConnection query in the GTFS GraphQL schema that is outputted through introspection.

This pr also allows to reset searchWindow as null in the planConnection query (in case it has been configured on server).

Issue

No issue

Unit tests

Added tests.

Documentation

In schema

Changelog

From title

Bumping the serialization version id

Not needed

[optionsome]

We need to decide if using a directive makes sense or should we just use the input type and field names as keys for the translations. Also, have to maybe figure out how to not construct the schema on each request.

[leonardehrenfried]

Can you resolve the conflicts?

[codecov]

Codecov Report

Attention: Patch coverage is 90.86294% with 18 lines in your changes missing coverage. Please review.

Project coverage is 69.82%. Comparing base (72019c0) to head (76db9b5).
Report is 53 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
...ner/standalone/configure/ConstructApplication.java	0.00%	6 Missing ⚠️
...a/org/opentripplanner/apis/gtfs/SchemaFactory.java	95.87%	4 Missing ⚠️
...ntripplanner/apis/gtfs/configure/SchemaModule.java	0.00%	4 Missing ⚠️
...pentripplanner/apis/gtfs/DefaultValueInjector.java	97.56%	1 Missing and 1 partial ⚠️
...entripplanner/apis/gtfs/GraphQLRequestContext.java	0.00%	1 Missing ⚠️
...standalone/server/DefaultServerRequestContext.java	50.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6339      +/-   ##
=============================================
+ Coverage      69.79%   69.82%   +0.03%     
- Complexity     17943    17953      +10     
=============================================
  Files           2046     2049       +3     
  Lines          76685    76776      +91     
  Branches        7829     7833       +4     
=============================================
+ Hits           53520    53608      +88     
- Misses         20423    20425       +2     
- Partials        2742     2743       +1     

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

[optionsome]

We need to decide if using a directive makes sense or should we just use the input type and field names as keys for the translations. Also, have to maybe figure out how to not construct the schema on each request.

We decided to not use directives (however directive wiring is used to inject the defaults). Used dependency injection to avoid constructing the schema on each request.

[leonardehrenfried]

If we say that we need the service, I'm fine with it. I don't think it is necessary though.

[t2gran]

Consider: A map and a bit of refactoring would make this code smaller and more readable. I switch might be faster but I doubt it. I would make builder for the map, so it would look like this:

 b = <new builder>;
 b
    // Add a requiered int
    .intReq("planConnection_first", defaultRouteRequest.numItineraries())
    // Add an optional string, since the argument is not a string the method dos the null check and calls `toString()`.
    .strOpt("planConnection_searchWindow", defaultRouteRequest.searchWindow())
    // Explicit more generic alternative
    .strOpt("planConnection_searchWindow", defaultRouteRequest.searchWindow(), Object::toString)

The comments are just to explain my code, I would strip those away and add JavaDoc on the metods instead.

[optionsome]

I did something like that in 76db9b5 . I left out the Object::toString and just called toString on the object, but I can change that if you want. I'm not sure if this is more readable for me since how the method calls get split on multiple lines sometimes, but it's not much less readable either.

[t2gran]

Is the method name correct? To me it looks like this only validate the schema. The schema used else where is created by Dagger? I am not particular found of this - this defeats part of the point of DI. Instead I think there should be unit-tests to test schema creation. Not sure what can go wrong when you start the server and create the schema based on custom config - that is not testable. Also, the schema should be created eagerly (not lazy) by Dagger and the server should go down almost tha same way as you enforce here - or did I miss something?

[optionsome]

I'm pretty sure that I tested that this does initialize the schema and it is not recreated ever again. That's why I named it like this.

Since the schema creation depends on configuration now, I didn't want to end up in a situation where the server starts up but can't serve GraphQL traffic due to some NPE for example. Ofc, it's possible to avoid those types of issues in other ways as well (thorough unit testing, null checks and/or wrapping the default value creation in a try catch).