[DRAFT] Prototype use of autotracking to optimize subscription behavior

[markerikson]

This PR:

• Has a totally WIP prototype POC reworking of Subscription and useSelector to try using autotracking to optimize subscription behavior and avoid executing subscriber+selector callbacks that we already know try to read state that didn't change.

For background on autotracking, see:

• https://www.pzuraq.com/blog/how-autotracking-works
• https://v5.chriskrycho.com/journal/autotracking-elegant-dx-via-cutting-edge-cs/
• https://gist.github.com/pzuraq/79bf862e0f8cd9521b79c4b6eccdc4f9
• Add experimental new memoizers: autotrack and weakmap reselect#605

Notes:

• This branch currently rewrites the existing Subscription.ts and useSelector.ts files. My plan is that if I can get this working, I would instead copy-paste the logic into separate createTrackedSubscription and useTrackedSelector files, and that you would enable the top-level tracking behavior by passing <Provider createSubscription={createTrackedSubscription}>. That way no one would have to pay the bundle size cost for the additional tracking logic unless they opt in, and all existing useSelector usage stays exactly the same.
• It assumes that the root state is an object, not a primitive. That should be the case in most apps. (Naturally, a bunch of our tests do have just a primitive like 0 as the state...)
• The existing useSelector test suite all passes. Either I've done something very right, or I've done something that has no use at all :)
• I have no idea what the performance cost is of any of this right now, or how it behaves in a full real-world-sized state tree + thousands of components. I'll have to look into that next. I know that this is doing a bunch of additional work at the top level to reconcile the new state tree vs the old one and mark fields as dirty. It's also having to do work to track dependencies and recalculate changed revisions, and those are still O(n). It's entirely possible everything I've got here is a waste of effort because you're still calling a ton of functions.

But now that I've got something that appears to at least run and pass tests, I can start doing more investigation.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit bbf7a4f:

Sandbox	Source
Vanilla	Configuration
Vanilla Typescript	Configuration