fix(insights): ensure the same token is used when rendered multiple times server side

[Haroenv]

• in insights middleware: ensure we read from the _initialResults (as insights starts before index is init'ed and the parameters aren't in the index, but in the main index)
• in getInitialResults: add the parameters to every index explicitly (it's not ui state so was missing otherwise)

other changes in this PR:

• something in the dependencies to prevent [Bug]: Something tricky with the latest babel/traverse babel/babel#16689
• use a cache in the server side react examples
• type userToken in SearchParameters

related to CR-6992

[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 59c9e64:

Sandbox	Source
example-instantsearch-getting-started	Configuration
example-react-instantsearch-getting-started	Configuration
example-react-instantsearch-next-app-dir-example	Configuration
example-react-instantsearch-next-routing-example	Configuration
example-vue-instantsearch-getting-started	Configuration

[shaejaz]

So does this mean the cache always needs to be manually cleared by the user on the server side? Maybe comment the reason for it in the examples? Or if you feel this would be very common, perhaps move it to instantsearch and have an optional opt out via a flag?

[Haroenv]

The client cache in the examples is a bit of a stop-gap solution, I'm exploring some options for a follow-up:

• the client automatically has a "one response cache" or a cache with a low TTL
• we "cache" (prevent the request) if the parameters are the same in InstantSearch (but can't find a good place for it)

With this temporary solution at least we have something to point users towards to avoid the secondary request with dynamic widgets.

[shaejaz]

Ah makes sense. lgtm.