Heuristic route fix as a local search move

[jcoupey]

Issue

This PR is a WIP toward fixing #737

Tasks

• Try adding TSP steps as local search moves
• Try adding regular heuristics steps as local search moves
• Benchmark
• Update CHANGELOG.md
• review

[jcoupey]

The advantage of using a regular heuristic instead of the TSP code would have been that it embeds the validity check and could potentially work in all contexts regardless of the constraints. The limitations I saw when testing are:

• in situations where all TSP solutions are valid (simple capacity constraints and wide TW), using heuristics does not work as well in term of overall cost and the operator is much less often picked.
• in other generic situations with more constraints, the operator does not really improve significantly the solutions despite reaching to always valid solutions, and there is a computing overhead.

The bottom line here is that applying the TSP code embeds the dedicated local search we have inside that code, so the solutions we come up with (if valid) are much better out of the box. The heuristic operator may provide solution that have a good potential for further improvements by other operators, but we don't know that and often discard these options based on not having any gain.

So the state here is that I still think it's really helpful to apply the TSP-based operator on some specific use-cases, but we should not add a too high computing overhead for situations where this is not really efficient. Thus the next steps are:

• roll back to the TSP-based operator
• implement required validity checks on top of the TSP operator
• measure overhead on the least favorable use-cases
• see if we can find a good way to automatically decide to switch that operator on/off

[jcoupey]

I've run a few tests and we definitely don't want to pay the price for this operator in non-favorable situations such as the usual VRPTW benchmarks: the computing time overhead is significant but the change in solutions is marginal because the new operator is seldom applied. In this situation we spend most of the added time trying route changes that are bound to fail because of tight TW constraints preventing most of the reordering options.

I went for a strong vehicle-level criterion to decide whether we should apply this operator or not: a vehicle has a "green light" flag if the intersection of all its compatible jobs TW contain the vehicle TW. This is quite demanding but does in particular cover any situation like CVRP, problems where all jobs have default TW or all jobs/vehicles have the same TW.

Maybe this criterion could be refined at some point, for example by checking only jobs in the current vehicle route. This may allow to run the operator on most of the routes say if only a single job has a TW constraint. But then we'd have to make the flag dynamic and update it upon each modification. For now I'm happy with a demanding criterion which means we get the benefit on obviously interesting instances, but we don't pay any computing time price on tighter instances.