High: stonith-ng's function cannot be blocked with CIB updates forever

In the high-load (or high-rate-config-change) scenarios,
pacemaker-fenced would be unable to provide service when basically DoS'd
with CIB update notifications.  Try to reconcile that with elevated
priority of the server's proper listening interface in the mainloop, at
worst, it will try to fence with slightly outdated config, but appears
to be less bad than not carrying the execution at all, for instance.
Other daemons might be considered as well.

Prerequisites:
- ClusterLabs/libqb#352
  (libqb used to contain a bug due to which one particular step in the
  initial-client-connection-accepting-at-the-server procedure that would
  be carried out with hard-coded (and hence possibly lower than competing
  events') priority, which backfires exactly in this case (once the
  pacemaker part is fixed -- by the means of elevating priority for
  the API end-point of fenced so that it won't get consistently
  overridden with a non-socket-based event source/trigger)

How to verify:
- mocked/based -N (see commit adding that module to mocked based daemon)

lib/common/utils.c

@@ -1031,7 +1031,8 @@ attrd_ipc_server_init(qb_ipcs_service_t **ipcs, struct qb_ipcs_service_handlers
 void
 stonith_ipc_server_init(qb_ipcs_service_t **ipcs, struct qb_ipcs_service_handlers *cb)
 {
-    *ipcs = mainloop_add_ipc_server("stonith-ng", QB_IPC_NATIVE, cb);
+    *ipcs = mainloop_add_ipc_server_with_prio("stonith-ng", QB_IPC_NATIVE, cb,
+                                              QB_LOOP_HIGH);
 
     if (*ipcs == NULL) {
         crm_err("Failed to create fencer: exiting and inhibiting respawn.");