Fallback to <script> loading behavior when preload is not supported

[timneutkens]

Based on #5737 (comment)

This will cause a warning in chrome/safari after 3s

[yoavweiss]

This will cause a warning in chrome/safari after 3s

Regarding the warning, its purpose is to avoid cases where people excessively preload content and do not use it afterwards. Happy to consider alternatives that would still maintain this goal, while enabling the use-case of same page speculative preloading.

[timneutkens]

@yoavweiss, so the way this currently works in terms of scripts:

• Next.js runtime / router / etc
• Commons chunk, if a module is used in 50% of all pages it's considered commons
• Script bundle per page

Now on server-side render we add <link rel="preload"> for these 3 scripts, they are all needed to instantiate the interactive page (React hydration)

Then there is <Link href="/path/to/route" prefetch> which is a preloading mechanism for subsequent pages (separate from the current route) built into our router. That feature is what this PR is about.

Previously we would inject <script async src="/pages/something.js"> which kept the spinner going until the page was loaded because all async scripts are waited for like that.

So this PR changes it to inject only the <link rel="preload"> when supported, so that the spinner is not blocked.

[timneutkens]

I think showing the warning makes sense in a way, since it forces users to think about what they're prefetching. We just need to document very clearly that the warning is safe to be ignored.

[timneutkens]

Going to ship this to canary