snd_worker: Make sure we never send an empty volume message

My commit 71315b2e "snd_worker: Don't send empty audio-volume messages",
fixes only one case of sending an empty volume message, if the client connects
to a vm early during its boot sequence, while the snd hardware is being reset
by the guest driver, qemu will call spice_server_playback_set_volume() with
0 channels from the reset handler.

This patch also applies both fixes to the record channel.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
red_worker: stream agent - fix miscounting of frames

Frames counting was skipped when the previous frame was already
sent completely to the client.
server/red_worker: streams: moving mjpeg_encoder from Stream to StreamAgent

The mjpeg_encoder should be client specific, and not shared between
different clients**, for the following reasons:
(1) Since we use abbreviated jpeg datastream for mjpeg, employing the same
    mjpeg_encoder for different clients might cause errors when the
    clients decode the jpeg data.
(2) The next patch introduces bit rate control to the mjpeg_encoder.
    This feature depends on the bandwidth available, which is client
    specific.

** at least till we change multi-clients not to re-encode the same
   streams.
mjpeg_encoder: configure mjpeg quality and frame rate according to a given bit rate

Previously, the mjpeg quality was always 70. The frame rate was
tuned according to the frames' congestion in the pipe.
This patch sets the quality and frame rate according to
a given bit rate and the size of the first encoded frames.

The following patches will introduce an adaptive video streaming, in which
the bit rate, the quality, and the frame rate, change in response to
different parameters.

Patches that make red_worker adopt this feature will also follow.
mjpeg_encoder: re-configure stream parameters when the frame's encoding size changes

If the encoding size seems to get smaller/bigger, re-evaluate the
stream quality and frame rate.
mjpeg_encoder: adjust the stream bit rate based on periodic client feedback

mjpeg_encoder can receive periodic reports about the playback status on
the client side. Then, mjpeg_encoder analyses the report and can
increase or decrease the stream bit rate, depending on the report.
When the bit rate is changed, the quality and frame rate of the stream
are re-evaluated.
mjpeg_encoder: modify stream bit rate based on server side pipe congestion

Downgrading stream bit rate when the input frame rate in the server
exceeds the output frame rate, and frames are being dropped from the
output pipe.
mjpeg_encoder: update the client with estimations for the required playback latency

The required client playback latency is assessed based on the current
estimation of the bit rate, the network latency, and the encoding size
of the frames. When the playback delay that is reported by the client
seems too small, or when the stream parameters change, we send the
client an updated playback latency estimation.
mjpeg_encoder: move the control over frame drops to mjpeg_encoder
mjpeg_encoder: keep the average observed fps similar to the defined fps

The actual frames distribution does not necessarily fit the
condition "at least one frame every (1000/rate_contorl->fps)
milliseconds".
For keeping the average frame rate close to the defined fps, we
periodically measure the current average fps, and modify
rate_control->adjusted_fps accordingly. Then, we use
(1000/rate_control->adjusted_fps) as the interval between the
frames.
mjpeg_encoder: add stream warmup time, in which we avoid server and client drops

The stream starts after lossless frames were sent to the client,
and without rate control (except for pipe congestion). Thus, on the beginning
of the stream, we might observe frame drops on the client and server side which
are not necessarily related to mis-estimation of the bit rate, and we would
like to wait till the stream stabilizes.
server: spice_timer_queue

Each thread can create a spice_timer_queue, for managing its
own timers.
server/red_worker: assign timer callbacks to worker_core, using spice_timer_queue

display channel - supplying timeouts interface to red_channel, in order to allow
periodic latency monitoring (see next patch).
red_channel: monitor connection latency using MSG_PING
red_worker: stream - update periodically the input frame rate

Periodically calculate the rate of frames arriving from the guest to the
server.
server/red_worker: enable latency monitoring in the display channel
red_worker: start using mjpeg_encoder rate control capabilities

This patch only employs setting the stream parameters based on
the initial given bit-rate, the latency, and the encoding size.
Later patches will also employ mjpeg_encoder response to client reports,
and its control over frame drops.

The patch also removes old stream bit rate calculations that weren't
used.
red_worker: support SPICE_MSGC_DISPLAY_STREAM_REPORT

update mjpeg_encoder with reports from the client about
the playback quality.
The patch also updates the spice-common submodule.
red_worker: notify mjpeg_encoder on server frame drops
red_worker: ignoring video frame drops that are not due to pipe congestion

A frame can be dropped if a new frame was added during the same
call to red_process_command (we didn't attempt to send the older
frame). Such drops are ignored.