InMemoryDataTree allows DataTreeModifications to be chained in a manner similar to a git branch via DataTreeSnapshot#newModification().

This means that a set of DataTreeModifications created by:

List<DataTreeModification> list = new ArrayList<>();
DataTreeSnapshot snap = dataTree.takeSnapshot();
for (int i = 0; i < 100; ++i) {
    DataTreeModification mod = snap.newModification;

    // ...

    mod.ready();

    list.add(mod);
    snap = mod;
}
for (DataTreeModification mod : list) {
    dataTree.commit(mod);
}

will observe an isolated snapshot. The problem is that maintaining the state can lean to an OOM, because a new snapshot is never taken and all those DataTreeModifications are not eligible for GC until the last modification commits.

This is problematic, as in a highly-loaded asynchronous system we may not arrive at a point where are no outstanding modifications – hence we never free the garbage.

Introduce a mechanism by which a user can request that a chain of (sealed?) DataTreeModifications can be rebased on top of a new DataTreeSnapshot. This mechanism needs to be able to fail just as DataTree.prepare() can.