CUSTOM: liver timer: immediate liver timer control on data pending and destroy

CUSTOM: liver timer: immediate liver timer control on data pending and destroy

Note: this patch is not a bugfix, it is a targeted modification to
improve timing and predictability for particular scenarios.

Note: this patch only applies to userspace tracing.

Part of this work might find itself upstream but most probably not in
this form. Deeper work should be done upstream to mitigate the real root
of the problem which is how the network protocol for live works and
lifetime management of the different component required for the live
feature.

Scenario #1:
=======
   System with high CPU resource restriction (base high workload 99% cpu load),
   High CPU count (32),
   Slowish network (ping ~60-100ms),
   Timing constraint for create, configure, start, stop , destroy , create ... cycles.

We see additional delay in the second cycles at the configure step
(enable channel). This delay seems to be the result of the execution of
a live timer iteration for the previously destroyed session (cycle N
-1).

The live timer for the N - 1 session is still present since it is only
stopped lazily after all associated streams are destroyed
(consumer_del_channel, unref_channel, consumer_stream_destroy,
consumer_del_stream, consumer_thread_data_poll).

To help this situation, stop the live timer on cmd_destroy. The live
timer does not have any real value for a session to be destroyed and ,in
most case, already stopped.

Scenario #2
======
   System with high CPU resource restriction (base high workload 99% cpu load),
   High CPU count (32),
   Slowish network (ping ~60-100ms).

The data pending phase can be aggravated by the live timer depending on
the network and CPU contention.

In the context of stable 2.9 and live reading, stopping the live timer
during the data pending phase of a stop command does not impact
functionality at the reader level for a single session. Note that for
stable 2.9 and as of lttng 2.13 a reader cannot hook itself on multiple
sessions. Hence stopping the live timer during the data pending stage
and starting it back does not have any foreseeable downside.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: Icf8ff6fa72b24ce221cdf866d134ee42f64c9291