Fix MessagePort transfer bug

[gterzian]

To investigate further, but writing it down already:

When a port is "transfer-received" into a realm, the port is made available to script by firing a MessageEvent containing it.

At that point, the port is, while already managed by the global of that realm, in a "pending" state because it might be transferred-out of it in the same task in which it is received.

It's "pendingness" relates mostly to incoming messages for the port that, if any were sent while it was in transfer, would have been buffered by the constellation.

While it is "pending", we don't ask the constellation to "complete the transfer", which essentially means sending the global the buffer of messages, if any.

The global queues a task to "mayde add the port" to a "managed" state, essentially to see if it has been re-transferred in the task firing the MessageEvent, or if it is still there.

If still there, the global then sends a message to the constellation asking to "complete the transfer".

This message is non-blocking, and the answer from the constellation is received sometimes later, at which point the buffered messages will be used to "sync-up" the port.

So, in between sending the message to the constellation, and gettting the "complete transfer" answer, script keeps running.

While no MessageEvent can be fired on the port in that time, since the constellation will actually keep buffering any messages sent until it handles the "complete transfer" request, at which point it will forward it's buffer to script, it's actually still possible for script to store the port somewhere and access it in another type of task, and transfer it out!

For example, a setTimeout could be used from the onmessage handler in which the port is initially received. If the timer fires after the "maybe add port" task, but before the "complete transfer" messages has been received by the constellation, we'll lose any messages the constellation would have buffered(because they will be received by the global who isn't managing the port by then anymore).

So, I think the simplest solution is the make the "complete transfer" call from script to the constellation sync. One could alternatively do something by sending the buffer back to the constellation if the port is gone by the time the answer from the constellation is received by the global, however that sounds a bit like asking for more troubles.

It's probably worth writing a test for, since this isn't covered by the current suite.