m4: Update manywarnings from gnulib

Fixes these noisy errors on Fedora 21:

gcc: warning: switch '-Wmudflap' is no longer supported
migration: Don't assert() if MIGRATE_DATA comes before attaching the agent

During seamless migration, after switching host, if a client was connected
during the migration, it will have data to send back to the new
qemu/spice-server instance. This is handled through MIGRATE_DATA messages.
SPICE char devices use such MIGRATE_DATA messages to restore their state.

However, the MIGRATE_DATA message can arrive any time after the new qemu
instance has started, this can happen before or after the SPICE char
devices have been created. In order to handle this, if the migrate data
arrives early, it's stored in reds->agent_state.mig_data, and
attach_to_red_agent() will restore the agent state as appropriate.

Unfortunately this does not work as expected, for main
channel (agent messages).
If attach_to_red_agent() is called before the MIGRATE_DATA
message reaches the server, all goes well,
but if MIGRATE_DATA reaches the server before
attach_to_red_agent() gets called, then some assert() gets
triggered in spice_char_device_state_restore():

((null):32507): Spice-ERROR **: char_device.c:937:spice_char_device_state_restore: assertion `dev->num_clients == 1 && dev->wait_for_migrate_data' failed
Thread 3 (Thread 0x7f406b543700 (LWP 32543)):
Thread 2 (Thread 0x7f40697ff700 (LWP 32586)):
Thread 1 (Thread 0x7f4079b45a40 (LWP 32507)):

When restoring state, a client must already be added to the
spice-char-device.
What happens is that a client is not being added to the char-device
when when MIGRATE_DATA arrives first, which leaves both
dev->num_clients and dev->wait_for_migrate_data value at 0.

This commit changes the logic in spice_server_char_device_add_interface(),
such that if there is migrate data pending in reds->agent_state.mig_data
but no client was added to the spice-char-device yet,
then first the client is added to the device by calling
spice_char_device_client_add(), and only then the state is restored.

=== How to Reproduce
To reproduce, add delays to the migration connection between
qmeu-kvm on the source host (SRC) and on the destination (DST).

Specifically I added a man in the middle DLY host between
migration ports from SRC to DST.

+-----+    +-----+     +-----+
| SRC |--> | DLY | --> | DST |
+-----+    +-----+     +-----+

DLY listens on port P1 (e.g. 4444) and DST listens on port
PINCOMING (e.g. 4444, from qemu-kvm '-incoming' command line option)

Precondition: make sure port P1 on DLY is accessible in iptables.
Option 1: use ssh tcp port forwarding
On DLY host run ssh:
  ssh DLY:P1:DST:PINCOMING DST
Then use the following migration command (on qemu-kvm monitor):
  client_migrate_info spice DST PSPICE
  migrate -d tcp:DLY:P1

Option 2: Use a simple proxy program that forwards
packets from SRC to DST while adding some delays.
The program runs on DLY, listens to port D1, upon
accept connects to DST:PINCOMING and forward all
packets from DLY:D1 to DST:PINCOMING.
Then use the same migrate command as in option 1:
  client_migrate_info spice DST PSPICE
  migrate -d tcp:DLY:P1

=== How to Reproduce Ends

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035184

Based-on-a-patch-by: Christophe Fergeau <cfergeau@redhat.com>
server: fix crash when restarting VM with old client

The server will reset the vdagent char device when the client does not
implement SPICE_MAIN_CAP_AGENT_CONNECTED_TOKENS. This will nullify
dev->sin and the following crash will be reached on restart:

 #0  0x00007fb05aa264a1 in spice_char_device_write_to_device (dev=dev@entry=0x7fb066ae5d30) at char_device.c:443
 #1  0x00007fb05aa27137 in spice_char_device_write_to_device (dev=0x7fb066ae5d30) at char_device.c:436
 #2  spice_char_device_start (dev=0x7fb066ae5d30) at char_device.c:798
 #3  0x00007fb05aa6a981 in spice_server_vm_start (s=<optimized out>) at reds.c:3795
 #4  0x00007fb0644b7f89 in qdev_reset_one (dev=<optimized out>, opaque=<optimized out>) at hw/core/qdev.c:241
 #5  0x00007fb0644b7918 in qbus_walk_children (bus=0x7fb06661e870, pre_devfn=0x0, pre_busfn=0x0,
     post_devfn=0x7fb0644b7f80 <qdev_reset_one>, post_busfn=0x7fb0644b6350 <qbus_reset_one>, opaque=0x0)
     at hw/core/qdev.c:422
 #6  0x00007fb0644b7848 in qdev_walk_children (dev=0x7fb0665f47a0, pre_devfn=0x0, pre_busfn=0x0,
     post_devfn=0x7fb0644b7f80 <qdev_reset_one>, post_busfn=0x7fb0644b6350 <qbus_reset_one>, opaque=0x0)
     at hw/core/qdev.c:456
 #7  0x00007fb0644b7918 in qbus_walk_children (bus=0x7fb06647cde0, pre_devfn=0x0, pre_busfn=0x0,
     post_devfn=0x7fb0644b7f80 <qdev_reset_one>, post_busfn=0x7fb0644b6350 <qbus_reset_one>, opaque=0x0)
     at hw/core/qdev.c:422
 #8  0x00007fb0644399fd in qemu_devices_reset () at vl.c:1830

After restart, qemu will reset the device instance (sin) when virtio
port is opened:

 #0  spice_char_device_state_reset_dev_instance (state=0x7fe4873876d0, sin=sin@entry=0x7fe486fb0c68)
     at char_device.c:667
 #1  0x00007fe47b277516 in attach_to_red_agent (sin=0x7fe486fb0c68) at reds.c:2838
 #2  spice_server_char_device_add_interface (sin=0x7fe486fb0c68, s=0x7fe486fb2e60) at reds.c:2962
 #3  spice_server_add_interface (s=0x7fe486fb2e60, sin=0x7fe486fb0c68) at reds.c:3104
 #4  0x00007fe484c69e57 in vmc_register_interface (scd=0x7fe486fb0c60) at spice-qemu-char.c:123
 #5  0x00007fe484ce96b4 in set_guest_connected (port=<optimized out>, guest_connected=1)
     at hw/char/virtio-console.c:89
 #6  0x00007fe484ba70ed in handle_control_message (len=8, buf=0x7fe486fbdf70, vser=0x7fe48739ae98)
     at /usr/src/debug/qemu-2.1.0/hw/char/virtio-serial-bus.c:382

Let's ignore the call to spice_char_device_{write,read}_to_device() when
dev->sin is NULL, similary to other conditions, such as dev->running.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1145919