Thanks to mscherer for the report.

We no longer risk deadlocking when sending actions, which in turn
enables pushing connections synchronously.

Doing this asynchronously was racy -- under extreme circumstances, a
client could be deleted before it was added.

If the writer gets congested, the whole group might be delayed.  Better
to drop the slow client in that case.

This simply indicates that the server closed the connection
before we received the close indication from the client.

Don't allow a user with a wildcard password entry to use the same
username as a user with a specific entry even at the same privilege
level.

A stat of a cached file is cheap, no need to micro-optimise.

We need to terminate all down connections synchronously, otherwise
we risk leaving open connections lying around.

We're already logging in the caller.

This reverts commit f4811e8c.

This turns out to be incorrect when a MediaEngine is attached.

We now need to deal with the case where a track disappears from the
labels array.

We used to destroy and recreate down streams whenever something changed,
which turned out to be racy.  We now properly implement renegotiation,
as well as atomic replacement of a stream by another one.

Webrtc 3.0.5 includes a fix for a hang in CreateOffer that may be
triggered by incorrect SDP.

The previous behaviour led to silent failures, which was confusing.

We used to signal connection replacement by reusing the same connection
id.  This turned out to be racy, as we couldn't reliably discard old
answers after a connection id was refused.

We now use a new id for every new connection, and explicitly signal
stream replacement in the offer message.  This requires maintaining a
local id on the client side.

We now add tracks after the stream has been pushed, so we need a lock
on down streams.  Also rework sendUpRTCP to reduce locking.

Don't break the stream, just ignore the SDP.