Move completed trace archive chunks to an "archives" sub-folder

Move completed trace archive chunks to an "archives" sub-folder

Users have expressed the desire to read all completed trace archive
chunks at once. Initialy, the requirement called for users to wait,
using the notification API, for chunks to be made available following
the completion of a rotation. Upon the reception of a rotation
completion notification, which contains the chunk's location, it would
be possible to safely consume the resulting trace archive chunk.

Given that using the notification API was deemed too complex for
certain users, it was decided that the creation of a folder of the
form "<start-time>-<end-time>-<idx>" must guarantee the readability
of its contents. This guarantee is currently not honored for the first
trace archive chunk. This is a known bug which will be addressed
before the release.

This requirement has evolved and it must now be possible for users to
point a reader to a session output directory, after an arbitrary
number of rotations, to consume all completed trace archive chunks
while tracing is ongoing.

To make this possible (and reliable), a reader must have a way to
infer which trace archive chunks are still being produced, and which
have been completed so as to not attempt to consume a trace that
is still being produced.

First, a quick refresher on the hierachy of a session output path.

Before a rotation occurs, a session output path has the following
hierarchy:

my_trace
  |__ust
       |__[...]
  |__kernel
       |__[...]

And, after four completed rotations:

my_trace
  |__<start-time>-<end-time>-0   <--- completed trace archive chunk
  |__<start-time>-<end-time>-1
  |__<start-time>-<end-time>-2
  |__<start-time>-<end-time>-3
  |__<start-time>-4              <--- trace archive being produced

As a consequence of this behaviour, it is not possible to safely point
a CTF reader to a trace output directory without a special
configuration option that would indicate that the reader should ignore
the usual lttng hierarchy ('ust' and 'kernel'). Indeed, it is not
possible to distinguish a completed trace from a trace being produced
before the completion of the first rotation of a session.

Moreover, relying on the format of the name of trace archive chunks to
infer their completeness is awfully restrictive in terms of our
ability to alter the trace archive chunk directory format in the
future.

This format is also not part of any CTF specification document meaning
that implementing this logic in a reference CTF
implementation (babeltrace) is ill-advised. It would be unexpected for
a reader to fail to read a trace simply because it is stored in a
directory of the form <ISO8601-timestamp>-<integer>, which is a
valid trace output directory.

Hence, this commit changes the hierarchy of the trace output directory
so that completed (and safe to read) trace archive chunks are stored
in an "archives" sub-folder under the tracing session output
directory. This results in the following trace output directory
hierarchy:

my_trace
  |__archives
  |   |__<start-time>-<end-time>-0 <--- completed trace archive chunk
  |   |__<start-time>-<end-time>-1
  |   |__<start-time>-<end-time>-2
  |   |__<start-time>-<end-time>-3
  |__<start-time>-4                <--- trace archive being produced

Pointing to the "archives" directory requires no LTTng-specific logic
to be implemented in the reader(s) to achieve the users' requirement.

It does require that users wait for the presence of an "archives"
directory in the trace output path.

Reference shell code is provided to implement such a check:
"""
if [ -d ${trace_output_path}/archives ]; then
  # invoke reader
fi
"""

Given that a user would have to wait for a first completed chunk to
appear or ensure (in whichever way) that a rotation has occured before
consuming trace archive chunks, this alternative does not seem more
complex.

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