Fix: ustcomm: application name uses the '-ust'-suffixed thread name

Fix: ustcomm: application name uses the '-ust'-suffixed thread name

During the 2.13 development cycle, the compatibility pthread_setname_np
compatibility layer was fixed (see 0db3d6ee). Unfortunately, this had a
detrimental effect.

Upon the registration of an application to the session daemon, its name
is sent as part of the 'struct lttng_ust_ctl_reg_msg' registration
message. The application name is sampled using lttng_pthread_getname_np
during the preparation of the message.

However, when the listener thread is launched, its name is changed
early-on to add a '-ust' suffix (see 01f0e40c). This suffixed name is
sampled and sent to the session daemon. Since, until recently, the
pthread_setname_np had no effect on most configurations, this had no
consequence.

I noticed that this has a ripple-effect in the generation of some
path names. For instance, in per-pid mode, snapshots end-up with the
following hierarchy:

/home/jgalar/lttng-traces
└── Mercury
    └── florence_jacques-20210514-162630
        └── snapshot-0-20210514-162726-1
            └── ust
                └── pid
                    └── hello-ust-332607-20210514-162538
                        ├── lol_0
                        ├── lol_1
                        ├── lol_10
                        ├── lol_11
                        ├── lol_2
                        ├── lol_3
                        ├── lol_4
                        ├── lol_5
                        ├── lol_6
                        ├── lol_7
                        ├── lol_8
                        ├── lol_9
                        └── metadata

Notice how the 'hello' application presents itself with the '-ust'
prefix. For such a short application name, it doesn't really matter
much beyond repeating the 'ust' unnecessarily. However, longer
application names quickly become less readable as we lose four of
the 16 precious allowed characters for a process name.

The procname sampled during the execution of the constructors is
reused. My understanding is that the procname stored in the sock_info
is already used for the 'procname' context.

The resulting hierarchy becomes:

/home/jgalar/lttng-traces
└── Mercury
    └── sylvie_rouillard-20210514-193524
        └── snapshot-0-20210514-193553-0
            └── ust
                └── pid
                    └── hello-466576-20210514-193514
                        ├── lol_0
                        ├── lol_1
                        ├── lol_10
                        ├── lol_11
                        ├── lol_2
                        ├── lol_3
                        ├── lol_4
                        ├── lol_5
                        ├── lol_6
                        ├── lol_7
                        ├── lol_8
                        ├── lol_9
                        └── metadata

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ibd6f4763c96ea5fb680f55e5cc3d250baca175b0