sessiond: trigger: run trigger actions through an action executor

sessiond: trigger: run trigger actions through an action executor

The `action executor` interface allows the notification subsystem to enqueue
work items to execute on behalf of a given trigger. This allows the notification
thread to remain responsive even if the actions to execute are blocking (as
through the use of network communication).

Before this commit, the notification subsystem only handled `notify` actions;
handling code for new action types are added as part of the action executor.

The existing `notify` action is now performed through the action executor so
that all actions can be managed in the same way.

This is less efficient than sending the notifications directly, but could be
optimized trivially (if it ever becomes a problem) when:
  - the action is a group containing only a `notify` action,
  - the action is a `notify` action.

Managing the new action types requires fairly localized changes to the existing
notification subsystem code. The main code paths that are modified are the sites
where `evaluation` objects are created:
  - on an object state change (session or channel state changes, see
    handle_notification_thread_channel_sample and
    handle_notification_thread_command_session_rotation),
  - on registration of a trigger (see
    handle_notification_thread_command_register_trigger),
  - on subscription to a condition (see client_handle_message_subscription).

To understand the lifetime of most objects involved in a work deferral to the
action executor, see the paragraph in notification-thread-internal.h (line 82)
to understand the relation between clients and client lists.

Overview of changes
===

Object state changes

Change-Id: I23290e94d98e781992661f0aee88de9986ed274f
---

As hinted in the notification_client_list documentation, defering work on a
state change is straight-forward: a reference is taken on a client list and the
list is provided to the action executor as part of a work item.

Hence, very little changes are made to the the two state-change handling sites
beyond enqueuing a work item rather than directly sending a notification.

Subscription to a condition
---

A notification client can subscribe to a condition before or after a matching
trigger (same condition and containing a notify action) has been registered.

When a client subscribes to a condition, it is a added to a corresponding
"client list"

Registration of a trigger
---

When a client subscribes to a condition, the current state of
that condition is immediately evaluated. If the condition is true
(for instance, a channel's buffer are filled beyond X% of their
capacity),

TODO:

Change-Id: I7f9bc197715c9ca008a4f1fcd4c86e01b6252dce
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>