Background
As part of work on migration diffs, it occurred that some upgrade tasks — those that have been implemented as QueryTasks, are very likely to cause incomplete upgrade issues.

1. In particular, this is the case when a module has a first delta that creates/modifies a node structure, and then a second delta which executes a QueryTask. There is no guarantee at all that the query returns non-persisted changes in that workspace.

• just as stated in the JCR spec:
  • implementations may or may NOT account for pending changes in the current session
  • see http://www.day.com/maven/jcr/2.0/6_Query.html#6.5%20Search%20Scope.
• even the QueryTask javadoc itself mentions it.

2. We don't save sessions between deltas, only between modules.

Lights, Camera, Action!
1. We introduce a NodeVisitorTask, which in a similar fashion as the QueryTask enables to specify matching criteria and #operateOnNode().

• We call for replacing QueryTask implementations with it.

2. We make it way more explicit that the QueryTask can only operate safely on persisted content.

• We log a warning whenever executing a QueryTask.
• In 5.4 we deprecate current constructor, and add a new one with a boolean flag in the following spirit: "I read about the limitations and I know what I'm doing". If that boolean is false (default), we will fire a TaskExecutionException and interrupt the upgrade (see followup ticket MAGNOLIA-5859).