[Segment Cache] Optimistic prefetch for search params (#82586)
When there is no matching route tree in the prefetch cache, before we
de-opt to a blocking navigation, we will first attempt to construct an
"optimistic" route tree by checking the cache for routes are likely to
be similar to the one we're missing.
If there's a route with the same pathname, but with different search
params, we can base our optimistic route on that entry.
Conceptually, we are simulating what would happen if we did perform a
prefetch the requested URL, under the assumption that the server will
not redirect or rewrite the request in a different manner than the base
route tree. This assumption might not hold, in which case we'll have to
recover when we perform the dynamic navigation request. However, this is
what would happen if a route were dynamically rewritten/ redirected in
between the prefetch and the navigation. So the logic needs to exist to
handle this case regardless.
The implementation in this PR is a bit of an incremental step; it's not
as general as it should be. Notably, it will bail out if the base route
tree contains dynamic metadata, because we currently don't store the
route tree separately from the metadata.
We are also currently special-casing prefetch entries with an empty
search string. To take advantage of the optimistic prefetch behavior,
there must be a prefetch entry for the target URL with no search params,
e.g. to navigate to a page at `/target-page?search=foobar`, you must
first prefetch `/target-page` (no search string). This is a somewhat
arbitrary limitation chosen as a concession to implementation
complexity; the empty search string is only used because it's the one
that's most likely to already be cached. We will generalize this later
to match any search string.
I've added some TODO comments to describe the work necessary to enable
this mechanism in more cases.
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
