Try moving RTKQ subscription state handling from a reducer into the middleware

[markerikson]

Currently, the biggest factor impacting RTKQ perf is that we dispatch some action for every hook that mounts, in order to track subscription state.

In v1.9 alpha, we initially tried adding a batching middleware that intercepts some of those actions and groups them into a single parent action. That helped, but it was single-purpose and could be seen as altering behavior. We've also been trying out an "auto-batch enhancer" that delays notifications, but that doesn't improve perf as much as the middleware.

We've come up with an alternate idea: track subscription status inside the middleware itself, rather than in the reducer. This would avoid the perf hit from all these actions being processed by the reducer (and also all the spam in the Redux DevTools action log).

Some caveats / things to consider:

• We're already tracking several other pieces of state in the middleware anyway (timeouts, whatever). We should consider adding a data structure that collects all these.
• It probably needs to be on a per-store basis somehow, since it's possible for one middleware instance to be used with many store instances (including in an SSR scenario)
• This may actually make SSR rehydration easier (?)
• The RTKQ DevTools panel does currently show a "Subs" tab with this data. We should consider flushing a subscriptionsUpdated action periodically so that the state still exists

[phryneas]

It probably needs to be on a per-store basis somehow, since it's possible for one middleware instance to be used with many store instances (including in an SSR scenario)

All those other data structures should already be per-store, so we should just keep rolling with that and keep it in mind when consolidating them - but there's nothing new to invent there :)

[phryneas]

• buildHooks checks if some endpoint has any subscribers yet - selecting from the state at this point. Worst case we could dispatch a "probe_hasSubscriptions" action, catch that in the middleware, return the data and never forward it to a reducer for that.

[markerikson]

Done by #2759 , assuming that works out okay.