Avoid unnecessary rendering for validation in dev (#95394)
We're currently doing some unnecessary rendering in dev if Instant
Validation is disabled. If we had a cache miss,
`prepareValidationInputs` was always performing a full render, but
that's not necessary if we're only going to run Static Shell Validation
-- all we need is to go up to the runtime stage and then abort, which
avoids waiting for uncached IO that isn't even needed.
This PR fixes this and also reworks `prepareValidationInputs` to not be
an absolute slog to read through. We do this by:
1. splitting up the partialPrefetching path from legacy path
2. separating *what* we need to render from *when* we render it -- if
rendering work is needed, we return a
[thunk](https://en.wikipedia.org/wiki/Thunk) (i.e. a lazily evaluated
value) that will run the render if/when needed.
This simplifies the logic and makes the code shorter (previously, it was
easy to get lost in `if/else`s that don't fit on one screen)
Unfortunately the lazy evaluation capability isn't currently very useful
(other than the improved readability of `prepareValidationInputs`):
- In theory, we could use this to delay the instant validation render
(if needed) until after Static Shell Validation passes -- that way, if
it fails, we wouldn't waste a render that gets thrown away. Currently
this is not the case because the client module warmup uses the chunks
from instant validation render. I think that we could remove this warmup
-- we're running right after a dynamic render of the page finished, so
i'm not sure how we could run into client modules that haven't been
warmed yet. However, I'm leaving that for a future improvement.
- However, if we need to do two renders (both for static and instant
validation), this lets us parallelize them pretty elegantly, so it is
useful for something
