Stratify the queue by progress

[Zannick]

A* is a great search algorithm for routing, but unfortunately in a state search space, it acts too much like a BFS and results in an explosion of states that runs the system out of resources, and even if we did have enough resources, would probably take too long to generate interesting solutions. When the graph gets larger, this problem will only get worse.

One solution to this problem is to prioritize getting solutions not guaranteed to be optimal:

• We have a few dedicated threads to taking existing states and looking for greedy solutions, but they are fairly ineffective due to the upper bound.
• Our old "score" heuristic took progress into account.
• Or we could add more variety to the way in which we select states from the queue.

This idea would involve tracking elements in multiple priority queues in the Queue struct. This could be done via:

• Separate queues, aka stratification. We have n queues that are essentially buckets, and elements get distributed to the bucket that corresponds with how many required items they've collected/how many locations they've visited. We can then provide both a standard way to get the element of min estimation, or the next at a particular level. And likely we would have to customize selection of elements for eviction.
• Multiple orderings. Internally, the queues would be heaps of indexes into a single vector of elements. Popping the min of any heap would result in the full $O(log\ n)$ heapify, probably not great for performance.

[Zannick]

The initial implementation just gets the minimum element at the lowest tier, but this seems to be causing a lot of retrieving from the database once the min element in the lowest tier is old enough. We ought to make the default pop_min and peek_min get the min element from any tier. And possibly we could evict the whole tier into the db.