CUSTOM: consumer: ust: relayd: perform 2 stage relay_add_stream

CUSTOM: consumer: ust: relayd: perform 2 stage relay_add_stream

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 lttng-live works and
lifetime management of the different component required for the live
feature.

Scenario
=======
   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.

A lot of time (3s) is wasted in the iteration loop of stream creation.
The consumer sendis the add_stream command for a single stream then wait
for a reply containing the stream id. Then the next stream is treated.

What can be done is to split this operation in two iteration/phase.
The send and receive phase. TCP guarantee ordering of send/recv call.
Thus, we can iterate over the stream and perform the send part. Then
iterate over the stream again to perform the receive part.

This could lead to deadlock in certain scenario were the receiving end
(lttng-relayd) have a small send buffer and receive buffer and we end up
blocking on the send phase on the relayd side.  This is more that likely
not applicable to our current use case since the reply from lttng-relayd
are ~4 bytes long. For 32 streams, we are talking about 128 bytes of
data to receive. This mostly disqualify this solution for upstream as-is
since we would need to validate these scenarios further. Async
communication can ease all this (either on lttng-relayd side or
lttng-sessiond), still a lot more work should be put into this for
direct upstreaming.

Still, it is good enough for our current usage pattern.

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