Dynamically compute additional search days

[leonardehrenfried]

Summary

In order to boost performance make it possible to configure the additional search days to consider when filtering the trips.

Issue

n/a

Unit tests

none

Code style

Yes.

Documentation

Javadoc updated.

[t2gran]

I am a bit unsure, but I think the additionalDays(Before|After)SearchTime can be simplified and improved - I think we forgot to question this when the new pattern index on running date was made.

[leonardehrenfried]

@hannesj @t2gran I've reworked the calculation according to your spec. However, I set the static maximum trip time because I can't remember how we wanted to pass that to the transit router. How did we say we wanted to implement that?

[hannesj]

@hannesj @t2gran I've reworked the calculation according to your spec. However, I set the static maximum trip time because I can't remember how we wanted to pass that to the transit router. How did we say we wanted to implement that?

I think we could have a parameter with max hours of travel duration, which could be loaded from the config, in a similar manner you originally proposed.

[t2gran]

Sorry for being a bit hash and direct in my review here 🤒, but I just trying to explain what I think is important from a design perspective. I think we need to break thing apart, before we can assemble them into better encapsulated components later.

[leonardehrenfried]

Sorry for being a bit hash and direct in my review here face_with_thermometer, but I just trying to explain what I think is important from a design perspective. I think we need to break thing apart, before we can assemble them into better encapsulated components later.

That's quite ok - it's what reviews are there for.

How about we talk about how to resolve the deeper architectural problems (time zones) tomorrow's meeting?

[hannesj]

I think we can merge this without the ability to configure the maxJourneyDuration, and instead do that after #3828 is merged.