Thanks! Merged.

Done with the review, feel free to merge after the stuff we discussed.

Unfortunately I fear this will have to wait until I have had time to catch up
with the review queue, unless you can convince Jendrik and Florian to let you
move to the front.

I just noticed that I didn't paste the pull request link:
https://bitbucket.org/SilvanS/fd-dev/pull-requests/31/issue742/diff

I ran experiments in debug an release mode with random shrinking and linear
merging (both do not require any distance information) and the four different
possible pruning options to test the different behavior of computing g- and/or
h-values:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue742-v1-debug.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue742-v1.html

No errors occurred and I think that one can now really prevent merge-and-shrink
from computing distances at all, except for goal distances when computing the
heuristic of course.

Here is the pull request, please don't feel urged (not a very large diff, but
neither extremely small. If I had to guess, I'd say 10-15minutes for looking at it):
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue742-v1.html

With issue707, we introduced the feature of determining which distance
information is required by the merge-and-shrink configuration. Hence if using a
merge-and-shrink configuration that does not require any distance information,
no distances will be computed. However, the merge-and-shrink code relies on
valid Distances objects at several places, even if not using the distance
information. Also, there is manual trigger that would compute goal distances
after computing the abstraction if not goal distances have been computed on the way.