next.js

016ba387 - Only opt into navigation PPR flow if prefetched route was PPRed (#68815)

Only opt into navigation PPR flow if prefetched route was PPRed (#68815) ### What & Why In the first iteration of `experimental.ppr`, we only supported it either being fully on or off. When enabled, the client router would check if the prefetch was fully static (rendered from the root) which was guarded by the `flightDataPath.length === 3` check. This codepath was only meant to be triggered in the PPR case. When we introduced "incremental" PPR, we still opted into the forked PPR router handling because the `__NEXT_PPR` env was still set. However, for a page that _wasn't_ PPRed, we have a problem: a "full" prefetch (whether it be from `prefetch={true}` or from the fact that it was a static page and we were able to prerender it at build time) would opt into the all of the PPR router handling. This meant that the router would see the prefetch, assume it was a static shell associated with PPR, and eagerly kick off a dynamic request to fill in the data. This resulted in duplicate calls for the dynamic data, and in some cases, a delay in navigating while waiting for the second dynamic request even though the router already had all the data it needed. This ensures we don't opt into the PPR navigation logic unless we know the prefetch we're working with postponed. If it did, then we need to kick off a dynamic request. If it didn't, it's a no-op, and the existing router logic can be applied. In the next PR, I remove the unforking of the two reducer functions, as there is no reason for them to be different since the only change in behavior is this one line that calls into the `ppr-navigations` behavior. ### How This leverages a header that we already have (`x-nextjs-postponed`) to signal to the router that it should enter the PPR cache node update logic. On initial render, we use the `renderOpts.postponed` flag since we do not have access to headers. Closes NDX-178