Fix messageport "GC'ed too early"

[gterzian]

Part of #25208, with regards to

• Figure out the "port GC'ed too early" issues: #24707 and #24810

I'm thinking we might want to switch to the "leak memory" strategy, where we would hold a Dom<MessagePort> instead of a Weak inside ManagedMessagePort

servo/components/script/dom/globalscope.rs

Line 256 in 709e069

pub enum ManagedMessagePort {

Then we could remove those when close is called on a port, as opposed to rely on the GC mechanism of Spidermonkey.

I haven't been able to diagnose what exactly triggers the "early GC" in the two issues mentioned, and I think for now we can simply assume that we cannot rely on SM to fully manage the lifetimes of ports.

Instead, so that it at least "works" when for example browsing Spotify, we could just leak them inside a Dom, and only drop them if the JS actually calls Close, or if the page is navigated away from.

Then later we could try to come-up with our own heuristics to GC ports that are logically unreachable.

The spec has a note on the topic: https://html.spec.whatwg.org/multipage/#ports-and-garbage-collection

[gterzian]

See also #24810 (comment)

Firefox has a special KeepAliveIfEventListnersFor helper that's used for this kind of thing. We should build that.

This might be an alternative to simply leaking the port inside a Dom.