dfs `start` type is inconsistent with the rest

[tko]

Not sure if intentional, but all the other algorithms take &N as the starting point, only dfs takes N

[samueltardieu]

Yes, this is intentional: contrary to astar/dijkstra/bfs/fringe, elements discovered during a dfs search (such as neighbours returned by the appropriate closure) are stored only in the path, and never in other lists. This allows the use of non-Clone types. However, it requires that we take ownership of start as to be able to insert it into the resulting Vec.

There is already a note to that effect in the documentation:

Note that the start node ownership is taken by dfs as no clones are made.