ctf: make msg-iter not use bt_packet_context_field

ctf: make msg-iter not use bt_packet_context_field

The bt_packet_context_field API exists so that the CTF message iterator
could store packet context fields in contexts where it doesn't create
trace-ir objects.  For example, in add_ds_file_to_ds_file_group, we use
a message iterator just to sniff the properties of the first packet of a
data stream file.

However, the CTF message iterator doesn't really use it anymore, it just
stores the relevant properties in fields of the ctf_msg_iter structure
and transfers them to the caller in ctf_msg_iter_get_packet_properties.

So the bt_packet_context_field API no longer has a reason to be.  This
patch makes msg-iter stop using it, so it can be removed.

Currently, the packet_context_field is created when needed, which is
just before reading the packet context, in
read_packet_context_begin_state.  A bt_packet is later created in
create_msg_packet_beginning, and the packet_context_field is moved into
the bt_packet.

If we want to get rid of the packet_context_field, it means we need to
create the bt_packet earlier (if not in dry_run mode), so it is
available in read_packet_context_begin_state, so that the packet context
fields are read directly into the bt_packet.  And to create the
bt_packet, the bt_stream needs to be available.  The bt_stream is
currently created just before sending the stream beginning message, in
ctf_msg_iter_get_next_message.

So this patch moves the creation of the bt_stream and bt_packet as early
as possible, just after we have read the packet header, in
after_packet_header_state.  In read_packet_context_begin_state, we can
then find the packet already created in msg_iter->packet.

This change made it necessary to set the dry run flag on the CTF message
iterator in add_ds_file_to_ds_file_group (which should have probably
already been there anyway).  This iterator is used to read the packet
context, which, previously, didn't trigger the creation of the bt_stream
and bt_packet.  But now that we create those earlier, it is necessary
to set the flag to avoid them being created.

It was also needed to change the check in after_packet_context_state to
know whether we are at the first packet, and therefore need to emit a
stream beginning message, or if we are at a subsequent packet, and
therefore need to skip that step.  We would previously check whether the
msg_it->stream field was set, but this is now always true given that we
set the stream earlier.  The only way that I found to fix that is to add
the boolean flag emit_stream_beginning_message in the message iterator.

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