fix: handle all options in sequence function

[dummdidumm]

preload and filterSerializedResponseHeaders
fixes #8061

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: 749e787

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	Patch

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

[Lucurious]

I'm wondering whether it would perhaps be better to take all preload and filterSerializedResponseHeaders options into account, as opposed to only the first ones.
If handle 2 determines that header X has to be serialized, and handle 1 only needs header Y to be serialized, isn't the desired behaviour to include both header X and Y?

Something like this (in case of the filterSerializedResponseHeaders):

const filterSerializedResponseHeaders = (name, value) => {
    let filter = false;

    if (options?.filterSerializedResponseHeaders) 
        filter = options.filterSerializedResponseHeaders(name, value);
    if (!filter && parent_options?.filterSerializedResponseHeaders)	
        filter = parent_options.filterSerializedResponseHeaders(name, value);

    return filter;
}

return i < length - 1
    ? apply_handle(i + 1, event, {transformPageChunk, filterSerializedResponseHeaders, preload})
    : resolve(event, {transformPageChunk, filterSerializedResponseHeaders, preload});

EDIT: I just noticed this was already discussed in the issue, so perhaps this comment should be disregarded...

[dummdidumm]

We decided on "first wins" because else there's no way to re-introduce a filtered header/preload (if we do &&-logic, meaning "only allow those that pass all") or to filter out one that was allowed before (if we do ||, meaning "allow those that pass for at least one").