Analyse remaining mutexes and remove any RouDi deadlock possibilities.

[elfenpiff]

Brief feature description

Since RouDi is our central daemon and the whole system is corrupted when it fails we can assume for now that RouDi with its inner logic never fails. But we have to ensure that RouDi is not corrupted by any external instance like a publisher application which holds a lock and dies which would lead to a deadlock in RouDi.

This means RouDi is allowed to block any arbitrary process including itself but no one is allowed to block RouDi.

1. When the publisher sends data it locks a mutex in chunk_distributor.inl which can be also locked by RouDi during the cleanup process. If the publisher dies while it holds the lock RouDi will deadlock.
2. The process manager is used in roudi.cpp with a smart lock. Is there a RouDi deadlock possibility.

Detailed information

• [ ] create a design document that specifies which samples a subscriber receives when it subscribes to a service

[elBoberido]

Small addendum. It's quite improbable to get the deadlock since a subscriber would need to subscribe/unsubscribe after the publisher crashed when holding the lock and before RouDi cleans up the resources of the crashed application. It's much more probable that RouDi crashes when trying to cleanup the locked mutex.