[Fiber] Add more tests and fix an issue with incremental error handling

[gaearon]

See individual commits.

Add more tests for incremental error handling

Added more tests that test how error boundaries behave inside different priorities.
These new tests are currently failing:

  ✕ catches render error in a boundary during partial deferred mounting
  ✕ catches render error in a boundary during animation mounting
  ✕ propagates an error from a noop error boundary during full deferred mounting
  ✕ propagates an error from a noop error boundary during partial deferred mounting
  ✕ propagates an error from a noop error boundary during animation mounting

The observed behavior is that unstable_handleError() unexpectedly gets called twice:

      "ErrorBoundary render success",
      "BrokenRender",
      "ErrorBoundary unstable_handleError",
  +   "ErrorBoundary render success",
  +   "BrokenRender",
  +   "ErrorBoundary unstable_handleError",
      "ErrorBoundary render error"

This is not a big deal but if people call error reporting services in unstable_handleError, they'll get each error twice on mounting.

Always reuse progressChild when starting Task work

The above problem happens because Task is a higher priority work than animated or deferred, and so it throws away the already progressed child. This is why we render the failed path twice before continuing with the success path.

As a fix, I changed it to always reuse the progressed child when we're working with Task priority. I’m not sure this is the right fix. Maybe we should only do this for error handling work. I couldn’t figure out how to come up with a counter-example to this so I’d appreciate special attention there.

Verify batched updates get scheduled despite errors

This just adds a few tests I planned to do earlier so that we don’t accidentally regress on them.

[acdlite]

The fix seems reasonable to me but I want to look at bit closer at how progressedChild and progressedPriority work before final approval

[sebmarkbage]

I don't think that this is correct. Let's say we had a very low-priority render that had started deleting one child but it never completed. Instead it did some other higher priority updates to it.

Then suddenly something in a boundary fails (or get another Task priority update). Then the child would be remounted instead of reused.

I don't have a better solution atm but I'll think about it some more. I don't fully understand how the failure case happens now.

Would always force unmounting children in an error boundary help with this case?

[acdlite]

Would always force unmounting children in an error boundary help with this case?

It would because we'd be recreating the whole tree instead of trying to reuse failed work... I think?

[gaearon]

Would always force unmounting children in an error boundary help with this case?

I'm not sure. Maybe let's come back to this after #8227?

[sebmarkbage]

@gaearon Can you explain why "ErrorBoundary render success" gets called after "ErrorBoundary unstable_handleError"? Why doesn't it just abort and go directly to the "ErrorBoundary render error" case?

[sebmarkbage]

I'll just flag this as needing changes since it seems like this is waiting for #8304.

[gaearon]

This was fixed by #8304.