Rwh event generation

[rherrell]

Most of the mainstream Event Generation capabilities are now functional on this implementation. Features added:

• subscriptions from Clients are correctly recorded
• CRUD requests to the core lib's API handlers (POST, PUT, PATCH, DELETE) are executed, and if those trigger associated ResourceEvents (created, updated, deleted) then the appropriate Events are sent to the appropriate Subscribers
• if Agents send Sunfish Core any such ResourceEvents which create, update, or delete Resources in the Sunfish database, appropriate events for each modification are created and sent to the appropriate Subscribers. Sunfish does NOT check that an Agent is subscribed to ResourceEvents featuring its own Resources, so watch out for loops. (Sunfish Agents will see the original Client request if it applies to an Agent owned Resource, so Agents aren't expected to be specifically subscribed)
• if a Resource is deleted, the entire subordinate branch in the database is also deleted. Sunfish Core will create a ResourceDeleted event for every impacted objected ( deleted object or modified object ) and forward it to all subscribers of such events.
• if a Resource is deleted, the Sunfish database is searched for other objects that contain navigational links to the deleted resource, and those navigational links are removed from those objects. Those objects are thus modified, and a ResourceChanged event will be generated for those objects as well.
• if a deleted Resource was renamed (aliased) by Sunfish to avoid name contentions, the alias assigned and used in the Sunfish database will be removed from the database.
• the Event Generation functionality is SYNCHRONOUS with handling the CRUD requests or Agent initiated events; this is not a 'production' code base. A robust production code base would queue the Event Generation and Event Notification processes and not put them in series with making the actual changes requested by the Client or Agent.
• The synchronous event generation happens after the requested CRUD operation is successfully completed in the Sunfish database, but before the original Request is sent a response.
• Errors in the event generation and notification phases DO NOT affect the response to the original request.

The number of interactions between the core CRUD features and the Event Generation features make it very hard to adequately test the huge number of corner cases and combinations of uploaded objects, so be prepared to debug such when working with different uploaded objects.

The recent changes in return values from the internal calling points confuse the pytest suite, so some of the pytest tests need to be changed still. We can't pass the merge requirements yet, but we can start looking over the major changes in the core library and event handlers.

[rherrell]

I have fixed the pytest script to expect the new return values (a true dict {} ) from the internal handle_event() entry point.