Signal and Message Reordering

At the moment, if two Proxy objects and wait on both of them for a signal or property change, the order in which you get the signals is not defined. This could be an issue if there is in fact a caused-by relationship between the two signals resulting that the user code relies on.

Possible concrete example: the Inner part of an Interface is updated by a task that polls the NameAcquiredStream to get a list of all names of a certain pattern (say, org.mpris.MediaPlayer2.*). A client registers a name, waits for dbus to acknowledge it, then sends a request to the interface that expects it to be registered using that name. However, the task scheduler decides to run the ObjectServer task first and so the interface will reject the request - even though it's valid.

Caching after lazy activation has the same issue - the NameAcquired on the well-known name might be processed after the first signal from the owner of that name, resulting in the proxy rejecting the mismatching signal.

Not sure how much of a problem this is, but it does have the ability to cause problems in some code - and it may become more important depending on how property caching works.

Related: #178 (closed)

A possible solution to both #178 (closed) and this would be to run the connect_foo closures in the MessageReceiverTask. Then you just need to document that all of the Stream APIs have the potential to lose or reorder inbound messages.

Update: this also applies to method returns that populate a cache, such as GetAll for properties cache or GetNameOwner/NameAcquired on proxies associated with a well-known name.