Fix assertion failure when a monitor is active and a message from the driver cannot be delivered

• monitor test: Log the messages that we monitored

  This is helpful while debugging test failures.

  Helps: #457 (closed)

• bus: Assign a serial number for messages from the driver

  From: @hongjinghao (commit message added by @smcv)

  Normally, it's enough to rely on a message being given a serial number by the DBusConnection just before it is actually sent. However, in the rare case where the policy blocks the driver from sending a message (due to a deny rule or the outgoing message quota being full), we need to get a valid serial number sooner, so that we can copy it into the DBUS_HEADER_FIELD_REPLY_SERIAL field (which is mandatory) in the error message sent to monitors.

  This fixes a denial-of-service vulnerability: if a privileged user is monitoring the well-known system bus using a Monitoring client like dbus-monitor or busctl monitor, then an unprivileged user can cause denial-of-service by triggering this crash. A mitigation for this vulnerability is to avoid attaching Monitoring clients to the system bus when they are not needed. If there are no Monitoring clients, then the vulnerable code is not reached.

  Co-authored-by: @smcv
  Resolves: #457 (closed)

• monitor test: Reproduce #457 (closed)

  The exact failure mode reported in #457 (closed) is quite difficult to achieve in a reliable way in a unit test, because we'd have to send enough messages to a client to fill up its queue, then stop that client from draining its queue, while still triggering a message that gets a reply from the bus driver. However, we can trigger the same crash in a slightly different way by not allowing the client to receive a particular message. I chose NameAcquired.