Data: Optimize withSelect to avoid generating merge props on equal props

[aduth]

Closes #7680
Closes #6466
Closes #7498

This pull request seeks to implement the data module's withSelect implementation to avoid a case where mapSelectToProps would be called wastefully when neither the state had triggered a change nor had incoming props changed (as a product of shallow equality comparison).

This had been effected in previous implementations leveraging componentWillReceiveProps, but was lost in the upgrade to using static getDerivedStateFromProps:

gutenberg/packages/data/src/index.js

Lines 300 to 301 in 95ef796

	componentWillReceiveProps( nextProps ) {
	if ( ! isShallowEqual( nextProps, this.props ) ) {

It required some refactoring to account for state changes made by the artificial trigger from the component's subscription, to handle generating new merge props on either a state change or incoming props change, while ensuring that the component only re-renders when either props or merge props are shallowly unequal, also ensuring that isShallowEqual is called at most one time per props sets during this render pass.

In future iterations, it may be worth exploring to see whether props and fromStoreUpdate can be omitted from state. I'd considered assigning instance variables in shouldComponentUpdate and the subscription callback, where in the latter we'd call forceUpdate to skip shouldComponentUpdate. The main downside to this is that shouldComponentUpdate should ideally not have side effects such as assigning instance variables.

Testing instructions:

Ensure new unit tests pass:

npm run test-unit

Observe lag or CPU usage differences from this branch in contrast with master.

[aduth]

While this is likely a valid optimization, in some testing this is still not even close to the same level of performance. Typing in the demo post, for example, is unbearably slow, even after these changes, when contrasted with the variation of withSelect from 95ef796.

[aduth]

In future iterations, it may be worth exploring to see whether props and fromStoreUpdate can be omitted from state. I'd considered assigning instance variables in shouldComponentUpdate and the subscription callback, where in the latter we'd call forceUpdate to skip shouldComponentUpdate. The main downside to this is that shouldComponentUpdate should ideally not have side effects such as assigning instance variables.

This approach turned out to be much more viable, and made a night-and-day difference to the usability of the demo post. I'm still not entirely clear what was problematic about the previous implementation: It may be that getDerivedStateFromProps is simply not performant, or due to the additional memory overhead of tracking props and fromStoreChange in state.

[mcsf]

The last iteration of this PR makes a huge difference for me when editing the demo post.

I'd have a second set of eyes on this, but it looks like solid work. Yes, concessions are made, but this is quite the hot path.

[gziolo]

This one fails in master because mapSelectToProps gets called twice. This is a very good indicator that this PR fixes the issue.

[gziolo]

Unrelated: we should rename mapStateToProps to mapSelectToProps.

[gziolo]

Yes, I can confirm that it works much better. I was able to confirm that we don't notice double re-renders anymore in both testing and when comparing with the master branch.
Although proposed code uses some not-recommended solution as noted in the inline comment, it is much easier to follow and in my opinion works exactly as we want.