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>