Improve test.remote reliability

[maloel]

During development I noticed many cases, even locally, of tests failing with output like this:

[C  ] -D- 11:55:48.216 client: +writer (server.903) publishing 'realsense/device-info' [realdds::topics::raw::flexible reliable] (dds-participant.cpp:144 [20052])
___rea[  S] -D- 11:55:48.216 broadcasting discovery notifications (dds-notification-server.cpp:161 [16444])
[  S] dy
[  S] -D- 11:55:48.278 server: broadcasting (dds-device-broadcaster.cpp:81 [7116])

test.remote uses a specific string ___ready\n to signify to the client that it's in a ready state.
Notice how, in the above, this string is split by a line that's output from another thread! This breaks it up, the client doesn't realize it's ready, and times out - failing the test.

This attempts to identify such cases and deal with them. So far it's worked in my testing. Hopefully it will help in GHA, too.

Likewise:

-I- Test passed
-D- waiting for remote to finish...
-D- 12:31:51.518 client: -writer (.203) publishing 'server/device/control' (dds-participant.cpp:151 [140585218340608])
terminate called after throwing an instance of 'std::system_error'
  what():  Resource deadlock avoided
-D-     test took 1.2171788215637207 seconds
-E- test-dds-control-reply: exited with non-zero value (-6)

Googling this shows this is the result of "when a thread tries to join itself." Try to avoid this, too...

Added some minor DDS stuff, in own commits that should be self-contained. No new functionality (sample-lost callbacks don't work yet because of an eProsima bug -- I reported it and they fixed it).

[OhadMeir]

LGTM