This has no functional change, but it is a requirement to remove the
lock that used to obtain the MemoryManager instance.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

... to avoid having to grab a lock when we receive a chunk of memory
over the migration socket. This will come in handy when we have
multiple threads for receiving memory.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

To allow for accepting more connections in the migration receive code
paths, we need to keep track of the listener. This commit adds a thin
abstraction to be able to hold on to it regardless of whether it is a
UNIX domain or TCP socket.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

We keep the listening socket around and accept as many connections as
the sender wants to open.

There are still some problems: We never tear these threads down
again. We will handle this in subsequent commits.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

In anticipation of using multiple threads for sending memory, refactor
the sending code to be in a single place.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

... to be able to re-use it when establishing multiple send
connections. I moved the receive socket creation out for symmetry.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

... to simplify sending memory from multiple connections in future
commits.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

For sending memory over multiple connections, we need a way to split
up the work. With these changes, we can take a memory table and chop
it into same-sized chunks for transmit.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

This does not actually use the additional connections yet, but we are
getting closer!

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

This will stop us from listening for more connections on the TCP socket
when migration has finished.

Tearing down the individual connections will come in a subsequent
commit.

Co-authored-by: Philipp Schuster <[email protected]>
On-behalf-of: SAP [email protected]
On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>
Signed-off-by: Philipp Schuster <[email protected]>

... after the VM migration finishes.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

We don't die if we don't manage to establish more than the initial
connection to the other side. To limit the weird failure cases, we do
die when the other side only accepts some connections, but not all.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>

This restores the old behavior/performance in case, we don't use
multiple connections.

On-behalf-of: SAP [email protected]
Signed-off-by: Julian Stecklina <[email protected]>