Offer config option to skip rendering when new state == old

[rjrjr]

We have been afraid to simply make this change because it will inevitably break so many existing workflows. But everyone writes code assuming this is how things work, and that causes our worst performance problems. Let's at least offer the option to turn that behavior on, and consider gradually moving to make that the default.

Also not that if an output is emitted but no state is changed, there is still no reason to re-render. It seems to me we can consider posting output and changing state as orthogonal things.

[steve-the-edwards]

So, with #992 we will add exactly this. See that PR for explanation and pertinent points. Tests are passing and results looking good re: the # of render passes.

A further step beyond this could actually be to record a path from the the root of the Workflow tree (R) to the node where the state changed started from the action (lets call this N).

I believe we only need to re-render the path of nodes from R-N as they are the only ones that can be affected by this state change, within the next render pass. That state change of course could have knock on effects for any and all of the other nodes but those would need to be applied in separate actions.

The path R-N could start as naive (render all nodes in the path and all the children of all those nodes), then we could optimize it even further where in the path R-N we only render a node A's child if that child is on the path R-N or if the state change to A has modify the props passed to the child.

I'm not sure how we would manage knitting together the cached renderings w/ new renderings in order to build the full rendering.

[rjrjr]

I'm not sure how we would manage knitting together the cached renderings w/ new renderings in order to build the full rendering.

I think you had a pretty clear idea on that this morning: we always render everything beneath a dirty node, and everything above it; but can use the cached renderings for the dirty node's peers.

[steve-the-edwards]

Fixed by #992