Fix: application SIGBUS when starting in parallel with sessiond

Fix: application SIGBUS when starting in parallel with sessiond

There is a race between application startup and sessiond startup, where
there is an intermediate state where applications can SIGBUS if they see
a zero-sized shm, if the shm has been created, but not ftruncated yet.

On the UST side, fix this by ensuring that UST can read the shared
memory file descriptor with a read() system call before they try
accessing it through a memory map (which triggers the SIGBUS if the
access goes beyond the file size).

On the sessiond side, another commit needs to ensure that the shared
memory is writeable by applications as long as its size is 0, which
allow applications to perform ftruncate and extend its size.

Fixes #623

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>