Shared memory and deactivated agents

[annevk]

This is a follow-up to #2521. JavaScript has the following requirement on agents:

An embedding may terminate an agent without any of the agent's cluster's other agents' prior knowledge or cooperation. If an agent is terminated not by programmatic action of its own or of another agent in the cluster but by forces external to the cluster, then the embedding must choose one of two strategies: Either terminate all the agents in the cluster, or provide reliable APIs that allow the agents in the cluster to coordinate so that at least one remaining member of the cluster will be able to detect the termination, with the termination data containing enough information to identify the agent that was terminated.

Boris came up with a scenario that doesn't quite meet this and I found one derived from that:

1. Tab A does a window.open to a similar-origin tab B. That similar-origin page starts a dedicated worker. That worker starts a child worker. Navigating B will terminate both workers.
2. Tab A has a cross-origin child frame B. B does a window.open to a similar-origin (with B) tab C. B starts a dedicated worker. A removes B.

For the first scenario B might be able to use unload to tell A, for the second scenario C is effectively lost with the APIs we provide today (you could do keep-alive pings and that might arguably meet the reliable API definition, but it's not great).

---

I think there are some solutions here where we could notify the agents within the agent cluster without making GC observable, though applications will have to be careful about cleaning up their objects as they might stay alive longer than desired otherwise. (This "memory leak" versus exposing GC tradeoff is what resulted in this not getting addressed last time around.

1. A suggestion from @lars-t-hansen is that SharedArrayBuffer is reference-counted and has a callback that is invoked each time an instance is added or removed. That is quite low-level and only works for SharedArrayBuffer.
2. An event that we dispatch to MessagePort's counterpart in the other still active agent whenever the agent whose global to which MessagePort belongs is deactivated for a deterministic reason (such as discarding the browsing context or navigation).