Fix memory leak after repeated setState bailouts

[acdlite]

There's a global queue (concurrentQueues in the ReactFiberConcurrentUpdates module) that is cleared at the beginning of each render phase.

However, in the case of an eager setState bailout where the state is updated to same value as the current one, we add the update to the queue without scheduling a render. So the render phase never removes it from the queue. This can lead to a memory leak if it happens repeatedly without any other updates.

There's only one place where this ever happens, so the fix was pretty straightforward.

Currently there's no great way to test this from a Jest test, so I confirmed locally by checking in an existing test whether the array gets reset. @sompylasar had an interesting suggestion for how to catch these in the future: in the development build (perhaps behind a flag), use a Babel plugin to instrument all module-level variables. Then periodically sweep to confirm if something has leaked. The logic is that if there's no React work scheduled, and a module-level variable points to an object, it very likely indicates a memory leak.

[sizebot]

Comparing: 0cac4d5...984fcb0

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	+0.04%	135.04 kB	135.09 kB	+0.03%	43.33 kB	43.34 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	+0.04%	142.50 kB	142.55 kB	+0.04%	45.51 kB	45.53 kB
facebook-www/ReactDOM-prod.classic.js	+0.03%	489.88 kB	490.02 kB	+0.02%	87.21 kB	87.22 kB
facebook-www/ReactDOM-prod.modern.js	+0.03%	475.17 kB	475.31 kB	+0.03%	85.01 kB	85.04 kB
facebook-www/ReactDOMForked-prod.classic.js	+0.03%	489.88 kB	490.02 kB	+0.02%	87.21 kB	87.22 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 984fcb0

[acdlite]

Tested in www sandbox