Also add a test.

We used to send all of the packets corresponding to a received packet
as a single burst, which led to persistent packet drops for clients
at the end of the queue.  Pace the writer, which introduces up to 1ms
extra jitter.

This avoids locking in estimate.

This avoids a situation when an RTCP sender never terminates.

It turns out that send on a closed websocket doesn't throw, so handle
this case explicitly.  Thanks to Giuseppe Castagna for noticing.

Also don't rely on tracks being immutable in sendRR.

Don't send SRs for tracks for which we have no time offset yet.
Send an unscheduled SR when we get our first time offset.

This was broken when we pushed user notifications into addClient.

Since the packet entries are already overdimensioned, there's no
need to add additional padding.

In principle, we should be receiving receiver reports only, but let's
be robust.

This avoids locking in sendRR.