lib: validate iterator message packets

lib: validate iterator message packets

Validate that messages coming out of iterators have sensible packet
values.  This applies to event and packet end messages: their packet
must match the packet of the previous packet beginning message.

Add a hash table to hold per-stream state, inside the
bt_message_iterator structure.  Since this state will only be used for
dev assertions, for the moment, only create it if BT_DEV_MODE is
defined.

Discard the per-stream state when the iterator seeks (after which the
iterator is expected to produce a new message sequence, starting from
scratch).

If the iterator uses auto-seek to implement "seek ns from origin", we
need to discard the per-stream state twice: once after seeking the
beginning, and once after consuming messages until the desired point.

When a wrong packet is detected, print an error logging message with
some details, before the failed assertion message:

    Babeltrace 2 library postcondition not satisfied.
    ------------------------------------------------------------------------
    Condition ID: `post:message-iterator-class-next-method:message-packet-is-expected`.
    Function: bt_message_iterator_class_next_method().
    ------------------------------------------------------------------------
    Error is:
    Message's packet is not expected: stream-addr=0x60d000001d80, stream-id=0, iterator-addr=0x611000004c80, iterator-upstream-comp-name="source.gpx.GpxSource", iterator-upstream-comp-log-level=WARNING, iterator-upstream-comp-class-type=SOURCE, iterator-upstream-comp-class-name="GpxSource", iterator-upstream-comp-class-partial-descr="", message-addr=0x607000004540, message-type=EVENT, received-packet-addr=0x607000004310, expected-packet-addr=(nil)
    Aborting...

The particular structure of the code is explained by the following
patch, which adds verification that the message sequence is as expected.
Both assertions (packet is expected, and message sequence is as
expected) need to know about the current packet (this state is
maintained by message_packet_is_valid), so must be in the same "for all
messages" loop.  Alternatively, they could both track the current packet
independently, but that would be redundant.

But this form also allows putting more info about the problematic
message in the abort notice, which I think is nice.

Change-Id: I176417d9ae7b04a9c16ff975e008e208b173e3d2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10448
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>