In order to maintain a logical stream of events, we need to make sure we
flush and queued change notifications before responding to any requests
for information from clients.

If we don't do this, it's possible that we emit an 'add' event that was
queued at the time of a 'DescribeAll' call _after_ the reply to that
call (which already contained the description of the new action).

In practice, this is not only logically incorrect, but it can also cause
problems.  If a change to action 'state' or 'enabled' occurs after the
DescribeAll but before the signal has been dispatched, it will be
ignored because an 'add' signal is already pending.  When that add
signal is sent, it will contain the correct data, but the receiver will
ignore it because it already saw the action in the DescribeAll reply.