flt.utils.muxer: initialize variable to silence -Wmaybe-uninitialized warning

flt.utils.muxer: initialize variable to silence -Wmaybe-uninitialized warning

gcc 4.8 shows this warning:

      CC       muxer.lo
    In file included from /home/smarchi/src/babeltrace/src/plugins/utils/muxer/muxer.c:26:0:
    /home/smarchi/src/babeltrace/src/plugins/utils/muxer/muxer.c: In function ‘muxer_msg_iter_next’:
    /home/smarchi/src/babeltrace/src/logging/comp-logging.h:145:3: error: ‘next_return_ts’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
       (void) BT_CURRENT_THREAD_ERROR_APPEND_CAUSE_FROM_COMPONENT(  \
       ^
    /home/smarchi/src/babeltrace/src/plugins/utils/muxer/muxer.c:1042:10: note: ‘next_return_ts’ was declared here
      int64_t next_return_ts;
              ^

I looked at the interaction between muxer_msg_iter_do_next_one and
muxer_msg_iter_youngest_upstream_msg_iter (which is the one that sets
next_return_ts), and I think the code is fine:

 * muxer_msg_iter_youngest_upstream_msg_iter returns either OK, END, or
   an error status code (< 0).  It does not return AGAIN, because it
   does not call the upstream iterators, it works with the data already
   available to the muxer component.
 * muxer_msg_iter_do_next_one, only uses next_return_ts when
   muxer_msg_iter_youngest_upstream_msg_iter returns OK.
 * When muxer_msg_iter_youngest_upstream_msg_iter returns OK, it always sets
   *ts_ns.

I think that initializing the variable to suppress this warning doesn't
hurt, and I don't see any other modifications needed to the code.

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