event.from: prevent interference between parallel calls

Since the new event.from API implementation was based on top
of the existing event.next implementation it was possible
for one thread to interfere with another because each event.from
*shared* the 'subscription' record. In particular CloudStack
suffered from the following interleaving:

thread 1: event.from ["vm/"]
thread 2: event.from ["task/"]
 <- event on vm
thread 1: return successfully
thread 2: fails with SESSION_INVALID because the subscription
  is marked as invalid in the on_session_deleted cleanup function

In this patch we cleanly separate the event.next implementation
(in the submodule Next) from the event.from implementation
(in the submodule From). It's now clear that all calls to
event.from use *separate* state, sharing only the session_id
which is used to allow session.logout to be used to unblock
blocked threads.

This patch strengthens the event.from postcondition: the only time
when an empty event set is returned is when the timeout has fired.
Previously empty sets could be triggered by the race:

1.     object is modified
2. event.from sees the modification
3.     object is destroyed
4. event.from cannot find the snapshot, omits the modify event

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
quicktest: add a test case for parallel calls to event.from

Sophisticated clients like CloudStack will issue parallel calls to
event.from, looking for different conditions. These calls should
not interfere.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Add nice Xapi_event .mli

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Don't "synchronise" domain 0's state with xenopsd

This results in domain 0's power_state being set to Halted, and
then the metadata being destroyed.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Support multiple xapis, configurable per-VM

To override the default xenopsd set:
  VM.other_config:xenops = org.xen.xcp.xenops.NAME

Observe the following changes:
  1. xapi needs all configured xenopsd to be online before it can
     complete the initial VM sync. The xenopsd list is hardcoded.
  2. the control domain's power_state is not being synchronised
     with any xenopsd because (a) we always assume it should be
     Running, anyone who sets it to Halted triggers horrible bugs;
     and (b) which xenopsd should "own" it anyway?

Signed-off-by: David Scott <dave.scott@citrix.com>
xenopsd: read list and the default setting from the config file

xapi startup doesn't fully complete unless it can contact all
the xenopsd instances it wants to manage. It's easier to setup
a working system if the list can be tweaked via a config file
rather than a recompilation.

Although it's possible to override a xenopsd per-VM, it's also
convenient to set a host-wide default via the config file.

Signed-off-by: David Scott <dave.scott@citrix.com>
Remove ocaml/xenops: this is all stale code

Signed-off-by: David Scott <dave.scott@citrix.com>
Remove ocaml/rrdd: this is all stale code

Signed-off-by: David Scott <dave.scott@citrix.com>
Remove Vmopshelpers

Note we still have small dependencies on Xenctrl (boot time memory)
and Xenstore (VSS snapshots)

Signed-off-by: David Scott <dave.scott@citrix.com>
Fix the RPM build

Signed-off-by: David Scott <dave.scott@citrix.com>