breaking: Remove dangerZone.trackServerFetches

[elliott-with-the-longest-name-on-github]

We had to make a breaking change in #9945, so we added this option to give people who knew it was safe an easy way to keep their apps running while they implemented fixes. Since we're releasing 2.0, we can remove this security-related override.

Closes #11234

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: a3a52bb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Conduitry]

Will dangerZone continue to show up in autocompletes and in the docs even though there's now nothing in it? Is this what we want?

[elliott-with-the-longest-name-on-github]

Will dangerZone continue to show up in autocompletes and in the docs even though there's now nothing in it? Is this what we want?

Yeah, wasn't sure what we wanted to do with that -- seems like it'd be good to have an established place to put experimental or security-related things like this, and it also seemed weird to remove it and re-add it later.

[benmccann]

hmm. I wonder if we should leave this in the docs for now with a note that it was only available in 1.0 in case anyone wants to refer to what the option did in 1.0. It's kind of unfortunate that would also expose it publicly though. Maybe there's a way to merge in type declarations that are only used for generating the docs

[elliott-with-the-longest-name-on-github]

We could always change it to trackServerFetches: never and mark it deprecated.

[benmccann]

That probably works well enough

[Rich-Harris]

I'd be okay with removing and re-adding later if we need it again

[elliott-with-the-longest-name-on-github]

I'd be okay with removing and re-adding later if we need it again

Just checking, did you see Ben's comment? Might be good to leave it in with an @deprecated tag for v2 and then remove it in v3.

[benmccann]

I would remove it from options.js if we can though and only leave it in the types

[dummdidumm]

We can mention it in the migration docs, then it still shows up in search somewhere, and we can remove it here

[benmccann]

That works for me. Let's start a migration doc with that one note in it as part of this PR so that we don't forget

[dummdidumm]

Started in #11199