Parse dynamic params on the client (#82185)
This is part of a larger effort to remove dynamic params from server
responses except in cases where they are needed to render a Server
Component. If a param is not rendered by a Server Component, then it can
be omitted from the cache key, and cached responses can be reused across
pages with different param values.
In this step, I've implemented client parsing of the params from the
response headers.
The basic approach is to split the URL into parts, then traverse the
route tree to pick off the param values, taking care to skip over things
like interception routes.
Notably, this is not how the server parses param values. The server gets
the params from the regex that's also used for routing. Originally, I
thought I'd send the regex to the client and use it there, too. However,
this ended up being needlessly complicated, because the server regexes
are also used for things like interception route matching. But this is
already encapsulated by the structure of the route tree. So it's easier
to just walk the tree and pick off the params.
My main hesitation is that this introduces some risk of drift between
the server and client params parsing; we'll need to keep them in sync.
However, I think the solution is actually to update the server to also
pick the params off the URL, rather than use the ones passed from the
base router. It's conceptually cleaner, since it's less likely that
extra concerns from the base server leaking into the application layer.
As an example, compare the code needed to get a catchall param value in
the
[client](https://github.com/acdlite/next.js/blob/09b16a816ff4d595b5111cb1a6de540838caf97e/packages/next/src/client/client-params.ts#L57-L61)
versus the
[server](https://github.com/acdlite/next.js/blob/09b16a816ff4d595b5111cb1a6de540838caf97e/packages/next/src/shared/lib/router/utils/get-dynamic-param.ts#L37-L84)
implementation.
Note: Although the ultimate goal is to remove the dynamic params from
the response body (e.g. FlightRouterState), I have not done so yet this
PR. The rest of the work will be split up into multiple subsequent PRs.
