MODE-1817 Corrected logic of concurrent removals

Added a relatively-simple test case that replicated the exact exception using my hypothesized scenario. The test creates separate threads to concurrently remove a specific node and (after synchronizing on a CyclicBarrier) save their changes. Thus, the transient state of each Session does not see the uncommitted transient state of the other Session, but both sessions are saved roughly the same time (in different threads so different transactions are used). But since both need to acquire the lock on the same parent node, only one session will proceed first to successfully remove the node. When the second session proceeds, it no accepts the fact that the node was already removed and proceeds accordingly.

(ACID transactions FTW!)

The fix was pretty simple: be aware that attempting to remove an entry in the cache may return null if the entry does not exist (i.e., was recently removed).