refactor viableBusStops query

[traines-source]

The viableBusStops query as it is generates about 6000 table/index scans (mainly on vehicle, availability, and tour) for a single query like Schleife - Dresden. This refactored version only a couple dozen, but maybe it's just hidden by the materialized CTE (which is materialized only to enforce the join order). It's also not faster (but also, for the queries I tested, not slower). While I think that the results should be equivalent, more testing would be needed for that I guess. So not sure if it even makes sense to merge this, or whether we wait how the system behaves when the tables grow.

The number of parameters for the prepared statement could become another issue, the limit is 2^15 (32k), and we're occasionally passing 10k...

[nilspenzel]

Wir hatten vor das Blacklisting grundlegend um zu schreiben. Die Idee wäre, dass Motis statt den Abfahrtszeiten an jeder Haltestelle nur noch ein großes Intervall in der Anfrage schickt und Prima antwortet in welchen Teilintervallen davon an welchen Haltestellen eine Taxifahrt möglich sein könnte. Dadurch würden die cte nur noch pro BusStop und nicht mehr pro BusStop und Zeit gebildet werden und sich das Problem mit der hohen Zahl index scans (hoffentlich) relativieren. Ich hatte dafür auf meinem Fork unter blacklist schonmal versucht das Prima-seitig umzusetzen, allerdings wären auch Änderungen in Motis nötig, daher hatte ich erstmal keinen Pull Request aufgemacht.
Wir rufen die Query in viableBusStops aktuell Batchweise auf, wenn es Bedenken gibt, dass diese zu groß wird könnte man als simple Lösung vielleicht einfach die Größe der Batches reduzieren