Potential memory leak when user worker terminates

[janpaul123]

We rely on the FinalizationRegistry notifying us when ZapBuffers get garbage collected. However, these never get called when you terminate a worker, which means that in such a case we never deallocate those buffers.

See this article:

it's safe to assume that engines will garbage collect, and finalization callbacks will be called at some later time, unless the environment is discarded (such as the tab closing, or the worker terminating). Keep this uncertainty in mind when writing code.

There are two ways in which a Worker can be terminated:

1. The close function within the Worker itself. We can monkey-patch it to do our deallocations when it is called; that's easy enough.
2. The terminate function outside of the Worker. This is trickier.

• We could discourage people from using it (and instead using close) by having a regular "keep alive" poll to our Workers (or just in development builds), and throwing an error or warning if a Worker disappeared.
• We could also be more sophisticated and keeping track of resources in each Worker so we can deallocate them when they disappear.
• However, these keep alive signals wouldn't work in cases where a Worker is synchronously blocked for a while — in that case there is no way to differentiate between long blocking versus being terminated, unless we deliberately unblock the Worker once in a while (e.g. by writing this in a custom stdlib Custom Rust stdlib #66).
• We could also monkey-patch terminate by having it throw an error, but people can override that or not load our library in the environment from which they call `terminate.

3. Silent termination of Workers by a browser. This is less common but it can happen.