Major Description
With OAK-2829, we'd have a mechanism inside of oak to have ability to quickly get a set of nodes changed between two root revisions. That collections needs to be managed by Oak itself. Otoh, mongo op-log already does this.
Opening this task to have implement reading part of such set of nodes (which can possibly be a super set of actual changed nodes) – considering quite a bit of this part can be re-used in the parent issue where underlying changes are maintained by Oak code.
As an added advantage, this implementation would avoid writing out/updating changes for mongo specific case.