Depending on when an RTCDataChannel is created, its underlying data transport might queue a task with open, message, or close events at any time. If this happens during transfer to a worker, the events might get lost. We need to specify it so this doesn't happen.

A precedent to follow here seems to be MessagePort.

It defines transfer steps to ship its port message queue over dataHolder.[[PortMessageQueue]] , as well as a default virtual unshipped port message queue ahead of transfer.

We should be able to cargo-cult something similar for RTCDataChannel.