Fix memory leak caused by shared abort signals

[sebinsua]

When using a shared AbortSignal across multiple requests, event
listeners were being added but never removed. This resulted in
memory leaks as each request's context remained in memory indefinitely.

The fix uses AbortSignal.any() to properly combine signals without
leaking memory, and eliminates a need for a manual event listener
approach. Additionally, this already handles the case where a signal is
already aborted, making the explicit .aborted check unnecessary.

[sholladay]

Awesome! Thanks for writing a test.

Is there a good way to detect the leak without importing a dependency? For example, if duplicate event listeners were being installed, maybe they could increment a counter in the test, which could be asserted at the end to have the expected count. Or if that doesn't work because the old listeners aren't triggered, then maybe we could directly count how many listeners there are with getEventListeners()? Not sure if that method is supported by abort signals.

[sebinsua]

The logic for jest-leak-detector is actually very simple so I could inline and simplify it if that would be preferred?

However, I'd recommend testing in this way instead of counting the number of event listeners, because otherwise you're testing the current cause of the leak instead of whether there is a leak or not, and (in an http client) you'll eventually get more bang-for-buck by having a generalisable way of unit testing for leaks. I also don't think the list of event listeners is generally exposed outside of Devtools, too. FWIW, I learnt the technique of testing for leaks from reading the unit tests of jotai.

FYI, the leak itself is due to the event handler closing over everything passed into Ky.create and then being attached onto something that is potentially long-lived (e.g. options.signal). You can forget to remove event listeners and it's fine normally as they'll be cleared up if the resource(s) they're attached to goes out of scope, but when they're attached to something that is long-lived it's a different situation. You can see in my test that without passing in an AbortSignal there isn't a 'leak' as by the end of the request nothing points towards this memory.

[sholladay]

If the goal is to detect regressions for this specific issue, I think counting listeners would be perfectly fine.

If the goal is to create a more general purpose system for detecting leaks throughout the Ky tests, then I agree that checking actual memory usage is much better. However, in that case, it would be preferable to implement it as a reusable utility, perhaps as a test macro so it can run assertions.

[sholladay]

I'll merge this now so we can get the fix out. It would be nice to have this refactored as a utility, though.