Florian and I started looking into this. We're using the opportunity to think about how to get rid of the factory-factory pattern mentioned in issue1209. While msg12037 suggests to turn landmark factories into task-independent components and landmark graphs into their task-specific counterparts, we started going down a different path within this issue. Specifically, with the intent to enable computing landmark graphs for different states using a certain landmark generation method (= technique implemented in a certain landmark factory), we deem landmark factories task-specific. At construction time, they take the task and precompute information about it that is useful to later compute the landmarks for any given state (e.g., which operators achieve a certain atom and need to be considered to compute shared preconditions in lm_rhw). Such data is independent of the state for which we want to compute landmarks, and we don't want to recompute it for each state-dependent landmark graph we want to construct.

This also means we're kind of reshaping the role of the landmark factories within this issue. This should be reflected in the documentation as part of this issue.

This might have some interaction with issue1209 where we want to change the way the task is passed to the factory.

Currently, our landmark factories can compute landmarks for the initial state of a planning task. I would like to change their implementations to be able to compute landmarks for arbitrary states and make it the responsibility of their callers to specify they want landmarks for the initial state. While our code base currently has no use case to compute landmarks for other states, this enables future extensions, such as the inclusion of landmark cycle heuristics which recompute landmarks in every state encountered during search.