Frame Visits: Cache Snapshot later in process

[seanpdoyle]

Follow-up to hotwired/turbo#441
Depends on hotwired/turbo#487
Closes #472

---

When caching Snapshots during a Visit, elements are not cached until
after the turbo:before-cache event fires. This affords client
applications with an opportunity to disconnect and deconstruct and
JavaScript state, and provides an opportunity to encode that state into
the HTML so that it can survive the caching process.

The timing of the construction of the SnapshotSubstitution instance
occurs too early in the frame rendering process: the <turbo-frame>
descendants have not been disconnected. The handling of the
<turbo-frame> caching is already an exception from the norm.

Unfortunately, the current implementation is caching too early in the
process. If the Snapshot were cached too late in the process with the
rest of the page (as described in hotwired/turbo#441), the [src]
attribute and descendant content would have already changed, so any
previous state would be lost.

This commit strikes a balance between the two extremes by introducing
the FrameRendererDelegate interface and the frameContentsExtracted()
hook. During <turbo-frame> rendering, the FrameRenderer instance
selects a Range of nodes and removes them by calling
Range.deleteContents. The deleteContents() method removes the
Nodes and discards them.

This commit replaces the deleteContents() call with one to
Range.extractContents, so that the Nodes are retained as a
DocumentFragment instance. While handling the callback, the
FrameController retains that instance by setting an internal
previousContents property.

Later on in the Frame rendering-to-Visit-promotion process, the
FrameController implements the visitCachedSnapshot() hook to read
from the previousContents property and substitute the frame's contents
with the previousContents, replacing the need for the
SnapshotSubstitution class.

[seanpdoyle]

Ideally, this implementation would call ParentNode.replaceChildren, but unfortunately, [email protected] doesn't support that API. It's introduced in [email protected], which might be worth upgrading to in a separate PR.

[seanpdoyle]

Since this depends on #487, it'd be best to skip the first commit when reviewing the changes in this branch.

[dhh]

Can you update this? Let's get this in.