Don't destroy roundtrip PyProxies automatically

[hoodmane]

There's a bunch of places where we want to destroy a PyProxy if it is being
handed back into Python. This way, if the user wants to keep the proxy around
they can return a copy() of it (whereas otherwise they would have no way to
destroy it after the JavaScript execution is ended).

function new_dict(){
  const dict = pyodide.globals.get("dict");
  const result = dict([[1,2],[3,4]]);
  return result;
  // Proxy is destroyed after it is returned!
}

If the PyProxy has roundtrip set, however, it is generally a bad idea to
destroy it in these cases. In many cases, this means that the object returned
to Python is actually unusable (because we get a destroyed double proxy).

One slightly annoying question is how to deal with the case where (1) we
want the return value NOT to be destroyed and (2) it may or may not be roundtrip

function f(px){
   // We don't want px to be destroyed so we have to return a copy (the copy
   // gets destroyed instead). But if px is roundtrip then the copy is also
   // roundtrip and neither gets destroyed so there is a leak. What to do???
   return px.copy();
}

Checklists

• Add a CHANGELOG entry
• Add / update tests
• Add new / update outdated documentation

[rth]

Do you want to include this in 0.22?

[hoodmane]

I think it would be nice to include. It makes create_proxy work a bit more reasonably.

[ryanking13]

There is a failing test, otherwise LGTM. Thanks @hoodmane!

[hoodmane]

We should also add a deprecation message for use like pyproxy.destroy("msg") rather than pyproxy.destroy({msg:"msg"}). Also, maybe it should be spelled message instead of msg?

[ryanking13]

We should also add a deprecation message for use like pyproxy.destroy("msg") rather than pyproxy.destroy({msg:"msg"})

Sounds good to me. (In that case, please also update the deprecation timeline!)

Also, maybe it should be spelled message instead of msg?

I'm +1 to it.