tor/changes/decouple_control_events

  o Code simplification and refactoring:
    - When generating an event to send to the controller, we no longer
      put the event over the network immediately.  Instead, we queue
      these events, and use a Libevent callback to deliver them.
      This change simplifies Tor's callgraph by reducing the number
      of functions from which all other Tor functions are reachable.
      Closes ticket 16695.
Refactor our logic for sending events to controllers Previously we'd put these strings right on the controllers' outbufs. But this could cause some trouble, for these reasons: 1) Calling the network stack directly here would make a huge portion of our networking code (from which so much of the rest of Tor is reachable) reachable from everything that potentially generated controller events. 2) Since _some_ events (EVENT_ERR for instance) would cause us to call connection_flush(), every control_event_* function would appear to be able to reach even _more_ of the network stack in our cllgraph. 3) Every time we generated an event, we'd have to walk the whole connection list, which isn't exactly fast. This is an attempt to break down the "blob" described in http://archives.seul.org/tor/dev/Mar-2015/msg00197.html -- the set of functions from which nearly all the other functions in Tor are reachable. Closes ticket 16695. 2015-07-30 16:43:37 +02:00			`o Code simplification and refactoring:`
			`- When generating an event to send to the controller, we no longer`
			`put the event over the network immediately. Instead, we queue`
			`these events, and use a Libevent callback to deliver them.`
			`This change simplifies Tor's callgraph by reducing the number`
			`of functions from which all other Tor functions are reachable.`
			`Closes ticket 16695.`