Don't use workspace move

Jackrabbit workspace.move operation is unreliable in a concurrent environment. This is because it operates directly on the local item state instead of the transient item state / copy-on-write mechanism used for session.move. This can lead to repository inconsistencies when a move is concurrent with write on the source folder. (When the write is done by a concurrent session on the source folder, the removal of the target child node entry is undone by the incoming change from the other session)

We should not use workspace.move anywhere in our code but prefer to use session.move instead. We should also consider implementing workspace.move in our decorator layer as a session move instead. (Impersonating a new session, doing the move operation on that session, saving the session, and logging out the session)

As far as I have been able to determine, currently workspace move is only used in the folder workflow implementation. I assume workspace.move was chosen instead of a session move in order to isolate persisting the changes made in the workflow action from other changes made in the session. However this does not seem to be a rule that is strictly applied throughout our codebase and with the deprecation of node.save it seems that such a policy is no longer supported by JCR.