This is part of meta issue987.

I think option 3) is the clean one, don't store costs in the landmark nodes/landmark graph at all.

A landmark doesn't have a cost as part of its definition. The cost is a property that is externally associated with the landmark. Landmarks were used for a long time for things like goal ordering before people ever thought of associating costs with them; costs only became a thing when people started using landmarks for heuristics. I think it makes more semantic sense to handle the costs on the side of the heuristic.

It should also give us some nice efficiency gains because I think there are currently places inside the heuristic where we reach inside a landmark node only for the purpose of fetching its cost.

Each landmark node has a member cost (previously called min_cost), which is set differently depending on the factory: The lm_rhw factory sets cost to the minimum cost of all (first?) achievers, but all other factories just leave the cost at 1. We instead want that the landmark cost is set to the same value no matter which factory is used.

I see two ways to implement this:
1) Set the cost in the constructor of LandmarkNode. This is similar to the current behavior of lm_rhw, which sets the cost of each node right after creating it.
2) Let lmcount set the cost. This avoids computing costs for landmarks which are later discarded, but is not that nice from a design perspective since it changes the landmark graph after it has been created by the factory (something we were getting away from in issue988). We could also store the landmark cost in the heuristic instead, but this doesn't seem very clean to me either.

For either option we loose some synergy with lm_rhw since it uses the result of a previous computation, but this is unavoidable if we want to compute costs for other factories. But we might anyway need to rethink how to compute costs correctly and how to handle 0-cost actions.