fix(xcat-core): one node's request to the install monitor blocks every other node

[dhilst]

The xcatd install monitor serves every installing node from one accept loop. It accepts a
connection, resolves the peer to a node and dispatches the request in line, so nothing else is
accepted until that request returns. On a flat el9 cluster, with one node holding three
connections that send nothing, a second node waited 5.7 seconds for the monitor's greeting.
The wait scales with the load: 1.7 s for one held connection, 9.7 s for five.

do_installm_service in xCAT-server/sbin/xcatd calls plugin_command directly in every branch --
next, installstatus, getpostscript, syncfiles, hpcbootstatus, locktftpdir. The per-request fork
that once stood there is commented out with the note that the node must be blocked, because
'nodeset next' and 'installstatus' for one node write the same chain row.

The monitor now gives each connection its own child and keeps that ordering per node: the child
for a node reads a pipe left by the previous child for the same node, and starts when that pipe
reaches end of file. Live children are capped at 64 and the rest wait in the listen backlog. The
parent reaps them and releases the gate, and a child that dies no longer takes the monitor with
it.

xCAT-test/unit/xcatd_install_monitor_concurrency.t lifts do_installm_service out of the program
and drives it with real clients on a port of its own. Without this change a second node waits
5.7 seconds for its greeting and the monitor does not survive a request that kills its handler;
with it the second node waits 0.004 s. Removing the pipe gate turns the ordering assertion red,
and raising the limit turns the backlog assertion red. Measured on the lab management node with
the patched binary installed, a second node waits 0.008 s against 5.716 s on the stock binary,
and a real getpostscript from the compute node is served by a forked handler

fix #7852

[viniciusferrao]

Daniel,

1. Could we preserve per-node ordering when a waiting child dies?
   With A running and B and C queued for the same node, killing B
   closes its pipe and lets C run before A finishes. The fork-failure
   fallback also closes the predecessor without waiting. Both paths
   can reintroduce the chain-row race. Please keep later requests
   behind the earlier work, with regression tests for these cases.

2. Could the concurrency test use a scratch PID file instead of
   /var/run/xcat/installservice.pid? Running it as root overwrites
   the live monitor’s PID file. The capped-monitor case also leaves
   its dead PID behind, since the restore happens before that case.
   Please redirect every PID-file access in the lifted service,
   rather than saving and restoring the host’s file.

Thanks!