TL;DR the triangle inequality strikes back

After a local search move implying a job addition in a route, we typically update the new job's earliest (resp. latest) dates, then propagate computing of earliest dates forward (resp. latest dates backward) in the route. For v1.6.0, this used to happen in TWRoute::fwd_update_earliest_from and TWRoute::bwd_update_latest_from. Those functions had checks to stop propagation here and here. The rationale is that when a new earliest date is not delayed past the previously known earliest date at some point, there is no point in checking further the rest of the route.

Now this check should actually have been written with == rather than <=, as it was in similar functions here and here. Actually the only situation where this matters is when after adding a job, the new earliest date afterwards is strictly lower. This only occurs when adding a job reduces the overall travel time (triangle inequality violation) and the service time at the new job does not even cover the difference. In that case we stop propagation, so we keep earliest/latest dates that are too pessimistic.

This affects v1.6.0 but the good news are:

1. Nothing breaks, the worst that can happen is that because of the pessimistic values for earliest/latest dates, some local search moves are discarded as invalid while they would be considered valid using the right dates.

2. This is fixed in master and for the next release. During the work on breaks at Feature/breaks #303 the above functions have been refactored and merged with the right checks here and here.