discoverd: Don't rely on service update order in TestReconnect

After reconnecting to discoverd, online services are ordered by the time they were last registered.

If a heartbeat interval has passed while doing the reconnect (e.g. on Travis), it is unknown whether services registered before disconnecting or the service registered during disconnection were registered last (as services are registered every heartbeat interval seconds), so the order of online updates after a successful reconnection is indeterminate.

In reality, the order of the updates doesn't matter, as long as we get all the correct updates, so here I have changed the test to check that all updates in the expected array are observed, regardless of the order.
I think so yes, we are iterating through the actual services, so to say "Expected [actual array] to contain [actual service]" doesn't make sense.

I guess this isn't related to the rest of the changes, so maybe should be in another commit.