Fix: output non-LTTng CTF trace with same relative path as input

Fix: output non-LTTng CTF trace with same relative path as input

Commit

  73760435c5a4 ("cli: automatically detect sources for leftover arguments")

changed the behavior of the CLI when converting non-LTTng CTF traces
[1].  The intended behavior, prior to this commit, is to replicate in
the output directory the directory structure from the input directory.

So let's say we have CTF traces at `a/b/c1` and `a/b/c2` (metadata files
inside those directories) and we do:

    babeltrace2 a -c sink.ctf.fs -p 'path="out"'

We expect to have traces output in `out/b/c1` and `out/b/c2`.

Before the introduction of automatic source discovery, the src.ctf.fs
component would receive `a` as the input path, recurse to find the
traces, and set the name of each trace to be the path of the trace
relative to `a` (`b/c1` and `b/c2` in the example above).  The
sink.ctf.fs component would then use add the trace name to the
user-provided output path to build the output path of each trace.

Now, when used with automatic source discovery (and especially since
they have lost the ability to recurse), src.ctf.fs components receive
the direct path to each trace (one trace per component).  So, in the
example above, that is `a/b/c1` and `a/b/c2`.  Since they don't have
access to the top-level directory the user specified, they can no longer
compute the trace name that the sink.ctf.fs component so desperately
needs.

Currently (since 48881202c2ef ("ctf: make src.ctf.fs not recurse")), the
normalized path is passed as the trace name.  So we end up with the
absolute path of the input trace under the output directory.

To restore the original behavior, this patch makes the CLI (which has
access to the required information)  compute the trace name the same way
src.ctf.fs used to do, and pass it as the `trace-name` parameter to
src.ctf.fs components.  It only does so when the trace has a single
input directory.

[1] This behavior only affects non-LTTng CTF traces, because sink.ctf.fs
first tries to build the output path using certain environment fields
(which LTTng traces provide), and only falls back on the trace name if
the required fields are not present.  So for LTTng traces (or other
traces that have the required env fields), the trace name does not
matter.

Change-Id: Iaba02fbae856ac5ddc11724613457bcc0b5b4019
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2026
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>