Linux: TransportRpmsg: Fix Mutex Deadlock Issue

Linux: TransportRpmsg: Fix Mutex Deadlock Issue

In an error recovery situation, it is possible that a
mutex deadlock could occur when MessageQ_delete happened
at the same time that an fd was being signaled about the
remote core error in the same process. This error could
occur if there are multiple MessageQs in the same process
communicating with the remote core that is doing recovery.

When MessageQ_delete grabs the lock, it then tries to
communicate with rpmsgThreadFxn, sending a message and
then waiting for a response. If at the same time, the thread
is processing a shutdown notification for an fd, it will
also try to grab the mutex, but will be blocked because
MessageQ_delete is holding the mutex. The rpmsgThreadFxn
will not continue until it gets the mutex, leading to the
deadlock.

The fix is to change the mutex_lock to a trylock when
handling shutdown notifications in rpmsgThreadFxn. If the
thread fails to acquire the lock, it continues processing
commands and will try again later to process the shutdown
request at a time when the lock is no longer being held.

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>