utils.muxer: fix bad behaviour caused by notification buffering

utils.muxer: fix bad behaviour caused by notification buffering

In some cases, buffering a single notification (that is, selecting in
advance what will be the next notification returned by the next call to
the "next" method) can introduce a bad behaviour in a utils.muxer
component.

For example, it is possible that an upstream notification iterator's
"next" method be called twice without any explicit sleep between both
calls even if the first call returned the
BT_NOTIFICATION_ITERATOR_STATUS_AGAIN status.

This patch fixes this so that there's no more buffering: the youngest
notification is chosen in the scope of the "next" method, with any
required newly connected port handling and upstream iterators to advance
done before, and any BT_NOTIFICATION_ITERATOR_STATUS_AGAIN status is
returned directly.

For this we introduce the concept of validity for an upstream
notification iterator. A valid upstream notification iterator is one of
which the current notification must be considered for the next muxing
operation. An invalid upstream notification iterator must be validated
(its "next" method must be called and return
BT_NOTIFICATION_ITERATOR_STATUS_OK) before we can consider its current
notification. In the muxer notification iterator's "next" method, the
youngest notification is chosen only when all the non-terminated
upstream notification iterators are valid, and only when there's no
unhandled newly connected ports left. When the notification is taken
from the youngest upstream notification iterator, it is invalidated: it
must be validated again during the following "next" method call.

Tests are updated accordingly. Two generated
BT_NOTIFICATION_ITERATOR_STATUS_AGAIN statuses in the source were
necessary for one expected BT_NOTIFICATION_ITERATOR_STATUS_AGAIN status
returned by the muxer: now the generated sequence of notifications and
what the sink sees are perfectly synchronized.

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