Missing SwapChoice options

[jcoupey]

The SWAP* operator implemented back in #507 goes through a set of precomputed options that seem interesting cost-wise to exchange jobs between two routes (not necessarily in place). A SwapChoice object embeds the move information along with the estimated gain.

For each pair of ranks in source and target route, SwapChoice candidates are stored in a set (starting here). The good part of using a set here is that the candidates are sorted by decreasing gain. So when evaluating feasibility we can stop at the first valid move and discard further checks.

Now the problem is that storing in a set will also prevent inserting different moves with the same gain. The result is that an invalid move inserted first could "shadow" a valid move with same gain, whose validity won't be checked at all.

This problem is probably only theoretical in the wild since the probability of having different moves with the exact same gain using real travel times in seconds is close to zero. But I've confirmed that this actually happens on a regular basis with benchmarks (e.g. Solomon instances), probably due to the use of euclidean distances and grid-based points. In that case, we're missing some valid SwapChoice that were handy, simply because they were not considered at all since they show the same gain as another choice that turns out to be invalid.