Make logger an option instead of globally shared state

[anilanar]

I need to create multiple query clients with different loggers.

Looking at the code, every single place where getLogger is called already has access to options.

The backward compatibility can be preserved by making the global one the default value for the relevant option field.

This proposal looks very trivial to implement; while also being more sensible and more principled than a global shared state.

[TkDodo]

Looking at the code, every single place where getLogger is called already has access to options.

which options are we talking about here? I think it should be an option on the QueryClient. Are you sure there is access to the QueryCient everywhere?

i would generally agree that this is a good idea - would also make it easier to stub out loggers in testing. If you think that works out and we can also get rid of the shared global state, please open a PR against v4 (the alpha branch) 👍

[anilanar]

The changes are really trivial. Couple decisions we need to make, with my preferences specified:

---

1. Keep setLogger with a @deprecated flag. It behaves exactly the same as before: when setLogger is called, it's immediately effective for everything.
2. Breaking change: Remove setLogger (and getLogger, which is undocumented).

My preference: (2).

---

1. Add setLogger to QueryClient so that users can change logger anytime they want, similar to client.setQueryDefaults.
2. Don't add setLogger to QueryClient, they can create their own logger which can have the capability of changing its logging behavior. Because this is already possible in user land, setLogger is unnecessary.

My preference: (2).

---

1. The default logger only logs when NODE_ENV !== 'production'. This is almost the same as the current behavior, except for persistQueryClient, which logs errors even in production, which was probably unintended?
2. Something else?

My preference: (1).

---

I'll make a PR based on my preferences.

[anilanar]

Voila: #3246