Merge branch 'release/0.6.0' into develop

Change-Id: I3811da2290b305b5a6c45325c9c2b4287a4c9eb3
updating poms for 0.7.0-SNAPSHOT development

Change-Id: I794a97483cc564966397872c003150805404d92a
threading: remove unnecessary executionQueue

MessageScheduler had an unnecessary queue. Now using the scheduledThreadPool for everything.

Change-Id: Ic2f765fb517dd4b9c81a59ee8392e4b23676015f
threading: rename longpollingcallable

Change-Id: I7d3e4f167f54e27ada11872904bc34f7b60a6238
threading: rename sendSync to executeSync

match naming for async and sync methods

Change-Id: I470d5ae1d2738c70b4aeeade08aefeb683ac8228
threading: move incoming thread pool to receiver

moved thread pool for incoming messages from the dispatcher to the receiver.
This simplifies the dispatcher code and allows a longer flow within a single thread (prep for MDC logging)
The Dispatcher test was incorrect, but used to work because of timing issues with an async dispatcher.

Change-Id: I09687c60aea18532373b8ae323102d9a9c2f4f95
threading: inject cleanup thread

classes that only need to perform simple cleanup tasks
(using minimal performance) using a scheduled executor
can have one injected for them.

Change-Id: Ib9be22b5d4f8de04631ed6da111157ae7ba4ee7f
threading: manage message queues directly in dispatcher

DispatcherMessageQueues was storing messages for participantIds unknown to the Dispatcher.
DispatcherMessageQueues was unnecessarily duplicating queues for oneway and request
DispatcherMessageQueues contained unnecessary executor to clean up queues.
instead now managing one queue for messages in the Dispatcher and using the
cleanup executor to remove messages with expired TTL.

Change-Id: I0a8775a6b51d17c00ac93d0ee8a4853093915652
threading: rename thread pools

added the prefix joynr. to the thread pool names

Change-Id: Iea7fffc7c0b91588b64b0d7d19e226e8fa1c4983
threading: unnecessary import

Change-Id: Ic83b3490da4c109d5e3499ee3bb7be8572452ba8
threading: use async calls in CapabilitiesDirectory

CapabilitiiesDirectory was using its own thread pool to make
sync calls to the global capdir async. Now using async calls
instead.

Removed sync versions from interface as well, as they were not being used.

Change-Id: I4c9ebb7ae309bbe245ca5e14baa580f5828061f2
cpp: Move MessageRouter to libjoynr subfolder

In order to be able to use the message router in libjoynr, the files
have to be moved to libjoynr module to be accessible by the cluster
controller and the libjoynr module.

Change-Id: Ife368edacdf259d0ad9d062888336ded1ee7f4f1
cpp: Use common method for address provisioning

Change-Id: I1c0ea83ef918f72dc86dacf88aa967fac00801da
cpp: No communication manager on libjoynr side

When the message router is instanciated on libjoynr side, there is no
communication manager needed. So it has to be removed from
MessagingStubFactory constructor.

Change-Id: Idb8622de4063010833f47dd2b071ab72be48ab9f
cpp: Add parent message router

Every message router has a parent router to resolve the next hops for
messages and to register the participant id's that are reachable via it
self.

Change-Id: Ifa509c6940c3c5d5447a90c177461e1ab1b4c435
cpp: Message router has in incoming address

Via the incomming address, a message router is reachable from outside.

Change-Id: I8559dcee07c526515c1c80a0a8f35469db8cc0b9
cpp: Implement add/remove hops from parent router

Change-Id: If5409e8ac372327756284e01be20a72dbe260cf6
cpp: Possibility to add local routing entries

This interface can be used only locally to add routing entries (e.g. by
the ProxyBuilder to register the inprocess address of the dispatcher).

Change-Id: I78ca4da827ecb1c6bdb57a32821846f95b09a935
Cleanup GlobalCapInterface

* drop type ProviderQosRequirment
* drop param qos from the lookupCapabilities method

Change-Id: Idb67b20b37387a7a45e920c50440ef851ae1bbc0
cpp: Use parent router to resolve next hop

When the destination address for cannot be found in the local routing
table, the message router asks its parent to resolve the destinattion
for the corresponding participant id. If this is possible the messaging
address of the parent router is registered as next hop for the
pariticipant id.

The request to the parent message router is implemented using
asynchronous calls, because otherwise threads (especially dbus threads)
are blocked and this causes a deadlock.

A further optimization is to save the current running requests to the
parent message router and schedule only one request per participant id.

Messages that could not be delivered are grouped by their destination
participant id and saved in a message queue. As soon as the destination
address for a participant id is known, all messages are send to their
destination.

Change-Id: Id896d4f916ff512c406613aee0c882662af90fbc