Notification iterator: generate automatic notifications when missing

Notification iterator: generate automatic notifications when missing

With this patch, a notification iterator object makes sure to always
provide a valid sequence of notifications to its user (a component which
has access to the private connection). "Valid sequence of notifications"
means no "stream end" without a corresponding "stream begin", no "packet
end" without a corresponding "packet begin", event notifications are
always surrounded by "packet begin" and "packet end" notifications, and
packet notifications are always surrounded by stream notifications.

To accomplish this, each iterator has its own queue of notifications.
When it detects that one or more notifications are missing when it calls
the upstream's "next" method, it creates the missing notifications and
adds them to the queue before the upstream notification.

Upstream can still provide the "stream begin", "stream end", "packet
begin", and "packet end" notifications in the correct order. In this
case, the iterator does not generate any automatic notification.

When the upstream's "next" method returns
BT_NOTIFICATION_ITERATOR_STATUS_END, the iterator adds any missing
notifications to its queue ("packet end" and "stream end").

To know what is the current packet of a given stream, and if a given
stream exists or not from an iterator's point of view, the iterator
keeps a hash table of streams to stream states. When the iterator
creates a stream state, it gets a reference to the stream, because the
stream must exist until its "stream end" notification (which is possibly
generated by the iterator). However, when the "stream end" notification
occurs, the iterator puts the stream reference and adds to it a destroy
listener which is reponsible for removing the stream state entry when
the stream is eventually destroyed. The iterator keeps the stream state
even if the "stream end" notification was emitted because it also
validates that, for a given stream during the iterator's lifetime, only
one "stream begin" and one "stream end" notifications are emitted.

This patch adds another API constraint: within a given component, a
given stream can only be referenced by notifications that are emitted
one a given port. The first port which emits a notification which has a
reference to a stream should remain the same for the stream's lifetime.
This is enforced by keeping a hash table of component to port in each
stream. This hash table indicates which port, within a given component,
has the right to emit a notification which references this stream. This
is validated by each iterator. For each component in this hash table, a
stream adds a component destroy listener to get notified when it should
remove an entry from the hash table.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>