Layout rendering dynamic optimizations

[fbarl]

In response to #1188:

Most relevant optimizations

• Translation/scaling of the nodes is now fully managed on the NodeContainer component level, so nodes are only rerendered when they change internally and not when they are repositioned in the layout.
• Caching the metrics that is displayed inside the nodes in the selectors.
• The search matching logic has also been partly moved to selectors and the difference can be felt when searching through the big graphs. Also, excessive recalculations in some special circumstances (e.g. when resfreshing the page with a broad search query) have been eliminated.

Layout changes

• Slightly decreased the distances between the nodes in the graph layout (to me it looks better this way).
• Doubled the treshold in the graph complexity heuristics as I believe we can now handle bigger graphs :)

Other changes

• Renamed subLabel to labelMinor everywhere for consistency with the grid mode and the backend naming.

Some ideas for the future

• Move zoomCache from NodesChart to a global state (would also solve Graph view zoom states get reset when switching to table view #2254).
• Make deep updates to the nodes when receiving delta and select only adjacencies when doing the graph layout (would solve Nodes layout runner caches node metadata #1353 again).
• Make all selectors pure, i.e. dependent only on the global state.

[davkal]

Excellent use of selectors. If anything I'd look into extracting adjacency for nodes into its own selector. Currently the graphLayout() selector is called on every received delta. Also, might be worth revisiting the deepEqual selectors that have been removed with this PR.

Otherwise LGTM

[fbarl]

@davkal PTAL, maybe just at the last commit, just to check if I've identified all the points you raised in the comments.

[jpellizzari]

I did some quick pseudo-science around wasted renders and found a significant improvement. I executed the same actions on both branches; here is the result:
Master:

This PR:

The code looks fine. I was not able to do a functional test, because we don't have a great way to roll out an experiment to dev, then roll it back with flux.

One comment around isEmpty in node.js, otherwise LGTM!

[fbarl]

Thanks for the review and the benchmarks @jpellizzari! I didn't expect the numbers to be so much better with my PR, but I think some of it is compensated with the slowness of deep comparison of the props (which now happens more often I think).