HAFAS backend: handle passing the same stop more than once

[deingithub]

Moin,

this is a patch aspiring to fix #90 and #83. Currently the HAFAS backend in various places picks the first stop on the route that matches the EVA/name of the requested checkin and checkout points, without considering the arrival and departure times.
The IRIS backend appears to have these checks in place already—

travelynx/lib/Travelynx.pm

Lines 767 to 776 in c04e58a

	# Note that a train may pass the same station several times.
	# Notable example: S41 / S42 ("Ringbahn") both starts and
	# terminates at Berlin Südkreuz
	my $train = List::Util::first {
	$_->train_id eq $train_id
	and $_->sched_arrival
	and $_->sched_arrival->epoch
	> $user->{sched_departure}->epoch
	}
	@{ $status->{results} };

i've added the same kind of checks to various places:

• checkin and checkout actions now send along a departure or arrival timestamp, the connection view also sends along a arrival-at-destination timestamp.
• the _checkin_hafas and _checkout_hafas functions do a somewhat-lenient match on the provided timestamp to find the correct stop.
• the index.pl work automatic checkout has also been patched to consider the timestamps.
• the history views and distance calculations pick the correct stops in the route based on journey arrival and departure times .
• when pulling from träwelling, the checkin and checkout actions also include the timestamps. I was not able to test that patch, even though it seems simple enough, I don't have a träwelling account and couldn't trivially set up a testing environment that includes oauth and stuff for interfacing with the site.

some notes:

• this patch doesn't fix this issue for the Travel API — i don't know what the correct approach with versioning it to add a new parameter with the required departure and arrival timestamps to disambiguate would be.
• travelynx's mental model doesn't really consider this issue and this is a kludgy workaround in a lot of spots. i tested this and it does work, but i can't guarantee that i've overlooked some spot where i should've added another check to pick the correct stop on the route. if i have, that might result in hard to reproduce bugs where parts of the system disagree where the journey starts and ends.
• checking in with IRIS always leads to an initial view where add_route_timestamps hasn't been called yet and no timestamp data is available. this is worked around by just ignoring unknown time values, but it would be a good UI improvement and reduce these edge cases if it was possible to delay rendering the view until add_route_timestamps has been called. i was not able to do that.
• it was extraordinarily annoying to work with the different kinds of data — arrival timestamps might be called sched_arr, sched_arrival, sched_arr_ts, sched_arrival_ts, each one might be a DateTime, an epoch seconds number or undefined altogether and handling them with anything less than the very verbosely-named helper function that i wound up writing is a recipe for hard to predict "can't compare DateTime with undef" or whatever issues. on the long term some comments and documentation on from what contexts these functions might be called would be greatly appreciated.

Cheers c:

[derf]

I'll probably postpone this until I have refactored and thoroughly unfucked the current timestamp situation in travelynx. It's the root of at least one nasty and hard-to-reproduce bug already.

[deingithub]

Okay, kein Problem!