Refactor forest's applyDelta to return a visitor

[jenn-le]

Description

Changes applyDelta to acquireVisitor so that multiple visitors can be used together.

[msfluid-bot]

⯅ @fluid-example/bundle-size-tests: +2.26 KB

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	438.56 KB	438.56 KB	■ No change
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	237.31 KB	237.31 KB	■ No change
loader.js	148.66 KB	148.66 KB	■ No change
map.js	46.54 KB	46.54 KB	■ No change
matrix.js	139.35 KB	139.35 KB	■ No change
odspDriver.js	89.09 KB	89.09 KB	■ No change
odspPrefetchSnapshot.js	41.58 KB	41.58 KB	■ No change
sharedString.js	155.59 KB	155.59 KB	■ No change
sharedTree2.js	240.51 KB	242.77 KB	⯅ +2.26 KB
Total Size	1.64 MB	1.65 MB	⯅ +2.26 KB

---

Baseline commit: 0bde699

Generated by 🚫 dangerJS against e41152b

[CraigMacomber]

previously this used to be enough to assert that no cursors (other than the one used foe the update) exist during delta application. With this change, this check (and likely a similar one in chunked forest) is no longer enough.

There are two approaches we can take to close this safety gap:

1. Add assert(this.forest.activeVisitor === undefined) into Cursor.setToAboveDetachedSequences (this will ban any use of cursors while you have a visitor)
2. OR: in the visitor implementation, before it makes each change, do this.invalidateDependents(); this.currentCursors.size === 1, and remove those checks from here (this will allow using cursors inbetween edits, for example inspecting the editiable tree on the delta events.)

Equivalent changes will be needed for chunked forest.

[CraigMacomber]

If you go with the second option, you might want to move before and after change into each individual edit as well, or at least update the docs on those events to clarify when they fire.

[yann-achard-MS]

Nice catch! Thanks for noticing that. I'm guessing we want option #2 given where we're headed.