GitLab

This is a leftover from initial experiments with recreating Hafas queries
issued by apps, but isn't actually needed.

We need instance-specific request flags to actually get any of those in
the responses though, working on that.

Also much closer to the OTP2 variant now.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Needs a different mode argument than OTP2, but otherwise just minor changes
to the GraphQL and result parser.

This further improves the result beyond what just outlier filtering gives
us.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Mostly brings the Entur journey GraphQL on the same level as the OTP2 one.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

GIT_SILENT

There's a number of constraints that need to be considered here, so better
do this centrally rather than having all backends deal with invalid
combinations.

That is, which individual transport options should be considered on the
first (access) and last (egress) leg of a journey. So far we always
implicitly assumed walking. Scenarios that are now also possible are e.g.
taking your bike and taking that with you on the train, or taking your car
to the station (and needing a place to park it there). Routing engines can
take all that into considerations, if we ask them to.

This is modeled based on OTP v2/Entur v3) but should cover the capabilities
of other engines as well.

This is only the request API so far though, support in any of the backends
is still missing, as is support for this in the result types.

Not sure yet though if we will be able to merge all of them in one, or
whether we need a configuration of all of those.

OTP generates valid short walking sections in a longer bike section
e.g. in case the bike has to be pushed for bit, e.g. due to steps or
restrictions on platforms.

This fixes access via a SOCKS proxy, ie. when tunneling out of the
limited Wifi here.

This now additionally lists all stops and applies the same 3 sigma outlier
filter we also use for GBFS already, and intersects the result with the
officially reported bounding polygon. This seems to reliably fix outliers
for all affected OTP instances.

Helps to actually sit next to OTP developers/operators for a bit :)

This needs special handling for the large auto-generated data tables to
keep the runtime of the static checks manageable.