fix(core): do not refetch disabled queries (TanStack#3223)

* fix(core): do not refetch disabled queries

with refetchQueries or invalidateQueries + refetchType "inactive"

disabled queries (=queries that have observers which are all enabled:false) are matched as "inactive"; this is okay when searching for them via findAll or for removeQueries, but the docs clearly state that refetchQueries / invalidateQueries do not refetch disabled queries, and that the only way to refetch them is via refetch returned from useQuery; this is important when using enabled to signal that some dependencies are not yet ready

some tests needed to be adapted because we used disabled observer + refetchQueries a lot. The easiest way to emulate the observers we wanted here was mostly with initialData + staleTime, and to get a real inactive query, we just need to subscribe + unsubscribe immediately

* fix(core): do not refetch disabled queries

add tests for refetchQueries + disabled

* fix(core): do not refetch disabled queries

update test to make more sense - title said disabled queries, but we had no disabled query; test now does the opposite of what it did before, but that's what this PR does :)

fix(types): use MutationKey instead of QueryKey for useIsMutating (Ta…

…nStack#3222)

Merge remote-tracking branch 'react-query/master' into alpha

# Conflicts:
#	src/core/notifyManager.ts
#	src/core/types.ts

fix(core): make sure batching finishes if exception is thrown (TanSta…

…ck#3216)

incrementing and decrementing transactions need to happen in an atomic operation, no matter what happens in between; if we increment, but never decrement, we will get to a state where transactions can never become zero - we're basically "leaking" an open transaction. This leads to no observers being informed ever again because we think we still have an open transaction

this can be fixed by using try/finally to always decrement the transactions

docs(ssr): Hydration caveat for Next.js' rewrites (TanStack#3209)

Adds a small section for a caveat about hydration when using some specific feature/configuration of Next.js

fix(types): export QueryClientConfig interface (TanStack#3203)

feat(persistQueryClient): improve persist controls (TanStack#3141)

* feat(persistQueryClient): improve persist controls

add restore/save/subscribe

* docs: update persistQueryClient and hydration

* docs: describe new persist features

* docs(persistQueryClient): correct option defaults

* feat(persistQueryClient): enable unsubscribe

* docs(persistQueryClient): clarify restoration

* docs(persistQueryClient): enable unsubscribe note

* fix(persistQueryClient): subscribe awaits restore

fix(queryObserver): fix data stability (TanStack#3183)

by making sure to memoize the structurally shared version of data rather than the raw one

Merge remote-tracking branch 'react-query/master' into alpha

# Conflicts:
#	src/core/query.ts
#	src/core/queryObserver.ts
#	src/reactjs/tests/useQuery.test.tsx
#	src/reactjs/types.ts

fix(queryObserver): memoized select functions should not return outda…

…ted values (TanStack#3140)

not all runs to createResult are saved on `this.currentResult` (optimistically created updates do not - we just create the result again later). With the fix from TanStack#3098, we made sure that memoized select does not run again in those cases by storing every run. However, that now means that we cannot rely on `prevResult.data` because it might still contain outdated data.

The solution is to store a pair of previous selectFn + data and return the exact data that was computed from the previous select fn if we get the exact same function passed