Cleanup Service derived classes

[laroque]

There are three classes that all inherit from Service and they've become a bit of a mess. The intent was:

• Spimescape for services that listen for and respond to requests
• Gogol for services that listen to and act based upon alerts
• Interface for ephemeral processes running client side (non-permanent subcommands, scripting, etc.)

The problems are:

1. Gogol and Spimescape both listen for messages and react to them. Some services need both behaviors (actually any Gogol should support responding to requests). This distinction makes little sense.
2. For services which implement logic (either based on requests or alerts), rather than direct hardware interaction, the procedure for communicating with other endpoints is tedious and error prone because it is multi-stepped. Interface implements nice utility methods for this, but having an Interface within an running Service is a recipe for threading and other troubles.

   Proposed Solution:

   • [x] Provider should implement the utility functions that are in Interface, making it much easier for and endpoint in one service to talk to other endpoints (done but untested on refactor/services branch).
   • [x] rename the Endpoint.portal member to Endpoint.service so that it is more clear what this thing is, and why self.portal and self.provider both exist. In most cases, self.portal.send_request(target, RequestMessage(msgop=<whatever>, payload=<something>)) will be replaceable with self.provider.get(<something>) (or set or cmd).
   • [ ] Spimescape should automatically make standard bindings on both alerts and requests exchange. It will need to support an on_alert_message() method which simply ignores any message received by default. Gogol then becomes a subclass of Endpoint which has configuration parameters which add extra bindings on the alerts exchange for the alerts it wants to process, and is then able to implement whatever logic is desired.
   • [x] Since Service inherits from Provider, that class should now be able to serve the purpose of the Interface class directly. When scripting etc, one could do my_service_instance.get(<something>) as is done now with interface.

     Short Term

Once the utility methods in provider are tested, I believe this eliminates the needed for the recoded versions of them in the esr scripting and greatly simplifies the interactions there and in multi[do,get,set] classes. The rest of the changes remain desirable but perhaps belong on the back burner since they aren't blocking progress.

[guiguem]

This issue was moved to project8/dripline-python#7