lib: remove stream activity messages

lib: remove stream activity messages

The stream activity messages were introduced to support eventual use
cases where the tracer could indicate when it stopped tracing and
started again.  To this day, no tracer which produces CTF provides this
information, so these messages are not currently useful.  Stream
activity beginning messages are only ever sent just after stream
beginning, and stream activity end messages are only ever sent just
before stream end.

Given that we will introduce a versioning system for the inter-component
communication protocol, which will allow adding new features, we can
remove the stream activity messages for now and add them at a latter
time, if need be.  This will reduce a little bit the amount of
boilerplate needed to implement a simple source.

So this patch removes the stream activity messages and handles all the
fallout.

One thing is that the stream activity messages optionally carried a
default clock snapshot, which is used by the trimmer component.  To
compensate for this loss of feature, the stream beginning/end messages
now have an optional default clock snapshot.

Impacts around the codebase include (on top of simply removing handling
of stream activity messages):

- sink.text.details: Update to include the default clock snapshot for
  stream beginning/end.
- flt.utils.trimmer: read clock snapshots from stream beginning/end
  messages (if not unknown).  These messages can now trigger the end of
  the trimming, if their default clock snapshot is greater than the end
  time of the trimmer.  Set the clock snapshot of the generated stream
  end message if the stream is ended by the trimmer's end bound (see
  note below for more details).  If the stream is ended because of a
  stream end message that is within the trimmer's bounds, the stream
  end message is not modified.
- iterator: handle stream message clock snapshots when validating clock
  monotonicity and doing an auto seek.

Note about clock snapshot handling
----------------------------------

This patch fixes a bug in trimmer's handle_message_with_stream function,
where it currently always returns BT_SELF_MESSAGE_ITERATOR_STATUS_OK,
even when something fails.  Changing it to return the "status" variable
(as I suppose the original intention was) uncovers a latent bug with
the clock snapshots of the "stream end" messages we
generate (or for stream activity end messages, before this patch).

Imagine a clock with a frequency of 1 and offset of 1000s.  This means
that the raw clock value 0 corresponds to the real time 1000s, 50 is
1050, and so on.  This clock is unable to represent real times prior to
1000s.  The sequence of messages generated by the source is:

1. Stream beginning, no clock snapshot
2. Packet beginning at 1050s (raw value 50)

Here's what happens in the trimmer's mind if we pass --end=200:

- Receive message 1, record that a stream is open
- Receive message 2, realize its clock snapshot is greater than the end
  bound.  Drop it and end the streams.
- Generate a stream end message, use own end bound (200s) as the clock
  snapshot
- Try to convert 200s to a raw value of the clock described above: it
  fails because 200s can't be represented by that clock.

This is fixed by recording whether we have seen a message with a valid
clock snapshot associated with the stream (which can therefore be
represented by the stream's class' clock class).  If we have, it means
that the clock snapshot we'll choose for the stream end message we'll
generate will be safe to convert to a clock value of that clock class.
If we haven't, we are not sure.

A similar problem happens in the iterator auto-seek code when using
'--begin=200' and the same setup as above.  We'll try to generate a
stream beginning message with clock snapshot 200s, which is invalid.

Note that this approach could be problematic in some corner cases,
here's a known one:

Once trimmer supports packet beginning/end messages without clock
snapshots (remember that whether these messages have a clock
snapshot or not is dictated by the stream class, it's not a choice per
message), this could happen:

- stream class defines that packet beginning messages don't have clock
snapshots, but packet end messages do.
- get stream beginning message without clock snapshot
- get packet beginning message without clock snapshot
- get event message with clock snapshot, greater than the end bound of
  200s
- since the stream class defines that packet end messages must have a
  clock snapshot, we can't get away by not putting one as is done by
  this patch.

A more complex solution along these lines would probably be needed:

- When trimmer receives the stream and packet beginning messages without
  clock snapshot, don't send them downstream but take a note of the
  state of the stream
- When we do get a first message with a clock snapshot, then send the
  required stream and packet beginning messages.
- If the trimming ends without having sent any content in this
  stream/packet, just pretend it never existed.

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