Solution states' best times in db do not match extracted history

[Zannick]

My current run is nearly at 2B rounds. The best solution is 947040ms, and I believe this comes from a pinpoint-minimized solution, which is essentially fully replayed rather than straight from the db. Feeding the preview of this solution into the route debugger replays it as 944258ms.

Solutions not pinpoint-minimized have the history extracted in reverse from the db, meaning there can be some race conditions, but generally every access should be retrieving a pair (history step, time to do that step) which should be accurate.

Another possibility is that the preview itself allows enough flexibility in movements that the route debugger is actually improving the route. For example, currently an instruction "Move... to [exit]" is being handled as a move to the exit's destination, rather than a movement to the spot with that exit and then taking that exit.

[Zannick]

For example, currently an instruction "Move... to [exit]" is being handled as a move to the exit's destination, rather than a movement to the spot with that exit and then taking that exit.

I might be concerned about this at some point, but it doesn't seem to be the case for this route.

[Zannick]

Plausibly the problem in #104 is happening here as well: the solution being added is inefficient somewhere without using warps, as the "Move... / Collect / Move..." would be turned into just "Move... / Move...". The preview only emits the last one, and then the route interpreter simply uses the shortest path.

[Zannick]

This is happening even more generally, and reliably during the search start sequence against the basic route which should be 1090723; when the route is recreated, the goal state's best time is 1094858.

[Zannick]

I found a couple of issues. One appeared to be a case of two condensed edges with different requirements and different times; even though the History item contains the elapsed time, recreate_step needed to choose the step that got there in the least time instead of the first in the list.

The next issue was the menuwarping one. This case was basically the route looping back on itself--we hadn't checked for that occurring, and it should be solved by retrieving the best elapsed time from the previous state, rather than relying on the state that delayed itself unnecessarily.

Together, these took care of pretty much all the issues... but it made new ones crop up that I haven't deciphered yet. I think it has something to do with chaining condensed edges in a way that violates the triangle inequality. That should be okay, of course, but I suppose this means that we haven't correctly updated the state db.