If the target doesn't have a connected passt-repair helper,
repair_wait() sets a timeout and forcibly calls accept4(), but if the
timeout expires, we don't report any error and proceed as if we had a
connected helper.

Later, in repair_flush(), sendmsg() will fail for each flow we try to
migrate with EBADF, and we'll handle that gracefully, but it makes no
sense to even try, and it also leads to noise in the logs.

Similarly to how we handle a missing repair helper in
flow_migrate_repair_all(), propagate timeout and other errors through
repair_wait(), and don't attempt to migrate flows if repair_wait()
failed.

Fixes: c8b520c0625b ("flow, repair: Wait for a short while for passt-repair to connect")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

...and time out after that. This will be needed because of an upcoming
change to passt-repair enabling it to start before passt is started,
on both source and target, by means of an inotify watch.

Once the inotify watch triggers, passt-repair will connect right away,
but we have no guarantees that the connection completes before we
start the migration process, so wait for it (for a reasonable amount
of time).

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

In vhost-user mode, by default, create a second UNIX domain socket
accepting connections from passt-repair, with the usual listener
socket.

When we need to set or clear TCP_REPAIR on sockets, we'll send them
via SCM_RIGHTS to passt-repair, who sets the socket option values we
ask for.

To that end, introduce batched functions to request TCP_REPAIR
settings on sockets, so that we don't have to send a single message
for each socket, on migration. When needed, repair_flush() will
send the message and check for the reply.

Co-authored-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>