The plan mode as described in #430 recently landed in master, replacing the usual solving approach behind Input::solve with a call to the new Input::check function.

As I focused on the implementation feature-wise, I simply re-used the existing matrix available after a request to the routing engine. As a result there are unnecessary calculations performed on the routing side: as task ordering is provided in input for all routes, we could actually get all the information we need by firing one route request per vehicle instead of a request for the whole matrix.

I'm not exactly sure what would be the most elegant way to do this without adding too much boilerplate. A "lazy" approach would be to not change the client code but add a sparse-filling function that would populate only the required entries in the matrix using route requests. A somewhat cleaner approach could be to change the routing Wrapper interface to expose the result of a route request. This response would then be used by the client code in choose_ETA to derive all required durations.

Something else to keep in mind: upon generating the solution, we populate the routes with distance values using the exact same route request, so it should actually be run only once and stored somewhere for reuse.