Proposal: fetch prop for HydratedRouter

[rossipedia]

HydratedRouter should support a fetch prop that allows you to customize the fetch implementation used in Framework Mode for route data requests. RSCHydratedRouter already provides this, so a) there's prior art and b) this would bring feature parity to both hydrated routers.

It's also a pretty useful power-user escape hatch, allowing for several use cases that are currently hacky or difficult to implement:

• Hosting SSR and data handlers on separate origins
• Adding custom headers / trace baggage to data requests
• Globally redirecting specific URL patterns to another origin
• etc

Usage is exactly what you'd expect:

<HydratedRouter 
  // same signature as window.fetch
  fetch={(request: RequestInfo, init?: RequestInit): Promise<Response> => {
    // Add custom headers, globally measure request timings, point the URL somewhere else,
    // or even load up the `Response` from browser storage for local-first scenarios.
    // The limit is your 🌈⭐️ imagination 🌈⭐️
    return window.fetch(...)
  }}
/>

[brophdawg11]

Linking a lot of related things this would probably address:

• global network error handling: Better error handling for actions, fetchers, revalidations (unexpected errors and network errors) #12804
• global retry mechanisms: Built-in Retry Mechanism #12892
• custom headers: Custom headers on form requests remix#4397

[brophdawg11]

This would also handle adding formData fields (#11285, #14194), but not on a per-route level. Do you see a way to conveniently do this from clientAction? the obvious solution is arguments to serverLoader but curious if there's ways that don't need to alter that API as well.

[rossipedia]

My personal opinion is that serverAction / serverLoader should probably be left alone. I feel like adding options/args to those methods would be opening a can of worms.

At the very most it should probably reflect this proposal and just add the same thing: a fetch option.

export function clientAction({ serverAction }: Route.ClientActionArgs) {
  return serverAction({
    fetch(input, init) {
      // input is an instance of `Request` that would normally go to `window.fetch`
    }
  })
}

Although I'm not entirely certain this is The Way™ either. I can easily see this spiraling out into "I want [specific fetch impl] to apply to this route and all children", which would be a reasonable request if this were possible, which would require either affecting how clientMiddleware works or adding Yet-Another-Route-Module-Export. Which probably isn't what we want.