React-instantsearch: Hydration of search client uses `query` from response instead of `request`

[Haroenv]

Describe the bug 🐛

This isn't usually a problem, except when a query rule changes the query (e.g. voltaren to voltaren®). This causes the cache to be missed & a request on the frontend to me made

I'd still need to check this, but I think this is only relevant for combining with algoliasearch@4

To Reproduce 🔍

Steps to reproduce the behavior:

1. go to an index which has an edited query (e.g. latency/instant_search for "edit_me")
2. enter that query
3. reload
4. see a query was done frontend, while it shouldn't be

This can be checked in the official next demo: https://codesandbox.io/s/github/algolia/react-instantsearch/tree/master/examples/next

Expected behavior 💭

No query should be done, even if the query done by the user doesn't match up with the query in the response / from the engine

Screenshots 🖥

Additional context

Relevant code is:

https://github.com/algolia/react-instantsearch/blob/7e883df4b39144efe7da9d2a713658075d337028/packages/react-instantsearch-core/src/core/createInstantSearchManager.js#L322-L474

[Haroenv]

The two options for solution are:

• https://github.com/algolia/react-instantsearch/pull/2941 (edit query before hydrating cache)
• https://github.com/algolia/react-instantsearch/pull/2945 (edit query before resolving findResultsState)

Either of those options have downsides (only works for query, as well as being more code in a "hot" path), however I can not find a way to use the params of the request directly.

A final option could be to read from the cache in findResultsState, however that's different in v3 to v4, and thus could be complicated

[yannickcr]

I'm more for #2945 as it seems cleaner to me to remove the duplicated query as early as possible, also that way we avoid exposing this logic to the client.