optimize server action refresh logic (#82674)
When a server action is in-flight and the user kicks off a navigation,
the router has handling to prioritize that navigation and "discard" the
action that was pending. This only discards it from the router state
perspective: the action is still run to completion and not aborted.
To account for the case where your action might have performed a data
mutation + revalidation, we'd eagerly refresh the router state after the
discarded action completes. However this isn't zero-cost:
`router.refresh` wipes the full router cache, which is wasteful if the
action you ran wasn't a mutation (ie, maybe it was just a GET).
Since actions already pass information to the reducer about when/if they
performed some sort of revalidation, we can use this to pass information
to the action queue, and it can use this to determine that a refresh is
needed, rather than always eagerly executing it.
While making this change, I noticed the original test case for it wasn't
actually working as expected. The random number in the root layout was a
`Math.random()` without any caching, so a navigation would have resulted
in a new random number, regardless of calling `router.refresh()`.