Remove leaks in the xenopsd <-> xapi caches

We have two caches:

  Xapi_cache: contains the latest pool VM metadata, translated into
     xenopsd format. Whenever the user changes the VM's name_label
     (for example), this is used to update the xenopsd metadata for
     next reboot.

  Xenops_cache: contains the latest runtime VM state, as queried
     from xenopsd. This is used to minimise the number of writes
     to the pool database.

The cache lifetime is tied to the lifetime of the metadata in xenopsd:
whenever we add to xenopsd we initialise the cache; whenever we remove
from xenopsd we remove from the cache.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-85940: Use xenstore rather than the VmExtra for active_{vbds,vifs}

Changing the VmExtra effectively changes the migrate protocol, which
is a bad idea at this point in the development cycle.

We also automatically delete the VBD and VIF metadata from xenopsd
when currently_attached is set to false. To make this work we:
  1. set currently_attached to true in Xapi_xenops.start
  2. only push down currently_attached VBDs and VIFs in the Xenopsd_metadata
     functions

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-85940: For all XenAPI calls with wire name "Class.method", add an alias "Class_method"

This provides an easy way for python's xmlrpclib to call functions
whose names clash with builtin keywords e.g.

  x = xmlrpclib.Server(url)
  ...
  x.event_from(session, [ "VM/%s" % vm ], "", 60.)

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-85940: Add a database-level operation to bump the generation count on a row

This is useful for the side-effect of generating an extra event on an object.

Note that we bump the generation count twice, which means that the new
count - 1 will guarantee to compare less than to an event generated
afterewards with the new count.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-85940: add event.eject(session, class, objref) which generates an event on a specific object

The return result of the event.eject will compare as strictly less-than
under a lexicographic sort of any event received by event.from which
is either this event or a strictly later one.

So to make sure all events have been flushed through your event.from loop,
it suffices to call event.inject, and wait for event.from to return a
strictly greater token.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-83940: generalise "with_migrating_away" to "with_events_suppressed"

This function temporarily stops events from xenopsd from being processed
for a particular VM. It is useful to prevent races between a foreground
thread and the background event thread e.g.

In Xapi_xenops.start:
  1. VBDs are set to currently_attached = true
  2. metadata is pushed to xenopsd
     <- at this point an event on the xenopsd VM would cause
        the VBD currently_attached field to be set to false so
        we block events
  3. the VM is started
     <- at this point it is safe to re-enable syncing.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Whenever we want to stop events from xenopsd for a particula
CA-85940: add an 'events from xapi' in parallel with an 'events from xenops'

Rename 'Events.wait' to 'Events_from_xenops.wait' and add
'Events_from_xapi.wait' which injects an event into the pool event
queue and waits for it to be processed.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-85940: extract a common 'wait_for_all_tasks' function in a new "Tasks" module

Also remove the knowledge of the structure of the event.from token
from code that links with the client -- all clients should treat this
as opaque.

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