Tests: lttng_live_server: support trace creation timestamps

Tests: lttng_live_server: support trace creation timestamps

Add support for a per-trace "creation time" as part of the live server
scenarios.

The objective of this change is to simulate situations where streams are
created and declared to the live client while other streams are already
being consumed.

The approach taken is to add a 'creation-timestamp' property to the
trace objects expressed in the scenario files. The creation timestamp,
when left unspecified is implicitly at the origin of the timeline.

Streams that exist when a client attaches to a live tracing session are
announced as part of the reply of
_LttngLiveViewerAttachToTracingSessionCommand.

When the creation timestamp is not at the origin, the live server starts
expressing the presence of new available streams once it delivers
index entries that start at, or after, the trace creation timestamp.

As part of the live protocol, newly-available streams are expressed by
setting the 'NEW_STREAM' flag as part of the 'flags' of a GetNextIndex
command's reply payload.

Hence, when handling the
_LttngLiveViewerGetNextDataStreamIndexEntryCommand, the server checks
for unannounced streams that have a creation timestamp lesser or equal
to the beginning timestamp of the index entry being delivered. If any
such streams are available, the 'NEW_STREAMS' flag is set as part of the
reply's flags.

When the 'NEW_STREAMS' flag is set, the client is expected to eventually
issue a _LttngLiveViewerGetNewStreamInfosCommand to list any previously
unannounced stream.

The _LttngLiveViewerGetNewStreamInfosCommand handler was previously
stubbed-out to only reply with the 'HUP' status (meaning the client
should hang-up) since the command was never used to announce new
streams. This doesn't mean that the command was unused.

When a live viewer session has reached a point where all of its streams
have been torn-down (no more data to consume), the live viewer
periodically polls the live server with the 'GetNewStreamInfos' command
to resume consumption when/if new streams appear.

Since the command's handler always returned with the "hang-up" status,
the live client would always gracefully exit at that point as it had
consumed all of the available data provided by the various tests.

The handler now implements the command to announce new streams, when
those are available. Thus, multiple statuses can now be returned:
  - OK: new streams are announced as part of the reply
  - NO_NEW: no new streams are available at this point, but there are
    still index entries (and data) left to consume as part of the
    current scenario's traces
  - HUP: all of the current scenario's streams no longer have index
    entries left to be delivered and all streams have been announced to
    the client.

In terms of the live protocol, the sequence of events leading to the use
of this command is:
  - The client issues LTTNG_VIEWER_GET_NEXT_INDEX to receive a new index
    entry
  - There is a new stream with a creation time <= to the next available
    index: announce it to the client by replying with an "inactivity
    beacon" (an empty index entry) + the LTTNG_VIEWER_FLAG_NEW_STREAM
    status flag
  - In response to the LTTNG_VIEWER_FLAG_NEW_STREAM flag's presence, the
    client asks for new streams by issueing the
    LTTNG_VIEWER_GET_NEW_STREAMS command
  - The server replies with a description of the new stream(s) containing:
    - channel name
    - relative path of the file
    - 'is_metadata' flag
    - stream id
    - trace id (which may not have existed up to this point)
  - The client then issues LTTNG_VIEWER_GET_METADATA to get any new
    metadata for the various traces it now tracks. In the case where a
    new trace was announced (a new trace id), this will be the moment
    when the client gets an initial fragment of metadata to initialize
    the trace class hierarchy (see lttng-live.cpp:481)

Notes
-----

The `is_sent` property of stream states is renamed to `all_data_is_sent`
as it felt ambiguous with regards to the new `is_announced` property
which expresses whether or not a stream has been made visible to the
live client.

Change-Id: Iecb86917b444f5068a445e8481749d34ad3b07c7
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11687
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>