Reset the progressive search cache from the received page, not the patched results state

[jamiefolsom]

What

useProgressiveSearch now decides whether a newly received page starts the hit cache over or appends to it from the results object and its page number, instead of comparing results._state with the previous state.

Why

InstantSearch re-renders widgets with the previous results while a new search is in flight, and it patches _state on that previous results object to the current state (its optimistic UI). So results._state does not identify the search that produced the hits. When a facet value arrives in the page URL, the facet widgets mount after the first search has been sent; the hook then saw the unfiltered hits stamped with the filtered state, reset its cache to them, and merged the real filtered hits into that. The page showed the facet as selected while listing unfiltered results (performant-software/core-data-places#793).

How

• utils/ProgressiveSearch.js adds getCacheAction(results, previousResults): skip when there are no results, when the object is the one already processed, or when it is InstantSearch's artificial placeholder; reset when the received page is 0; merge otherwise.
• The hook uses it, tracks the last results object instead of the last state, and notifies observers once the last page is cached. The dequal comparison and its in-place deletion of page from the state objects are gone.

Verified

• Six unit tests for getCacheAction (the package had none before; they run under the root jest).
• On a local FairData Sites dev server against the padp staging index, with this build installed: a facet in the URL now lands on the filtered count (8 of 45), unfiltered loading with a page size of 10 still reaches all 45, and ticking and unticking a facet by hand narrows and restores the list.

Flow was not run: the repo's .flowconfig uses an option the installed Flow version rejects, which predates this change.