Fix a race condition in Discovery/endpoint creation

[ohuopio]

This fixes a race condition, which was present because the AddEndpoint (reader/writer) commands were processed concurrently in DP event loop & Discovery. The fix is to move sending the Discovery command from the user-level function to DP event loop, which sends the command after it has actually created the RTPS endpoint.

Here's an example of how the race condition resulted in local-remote endpoints not matching:

1. RustDDS discovers a remote reader on a topic that the user has not yet created a DataWriter on
2. User creates the DataWriter
3. The AddWriter command is sent simultaneously to both DP event loop & Discovery
4. The command is processed first in Discovery. It notices that this topic already has a remote reader (discovered in step 1), and therefore it sends the UpdateReader command to DP event loop
5. In the DP event loop, the UdateReader command from Discovery is processed before the AddWriter command from the user thread. Therefore, the local writer does not yet exist when processing UpdateReader
6. DP event loop does not find a matching local writer for the reader of the UdateReader command, since the writer does not exist yet
7. DP event loop processes the AddWriter command & creates the local writer
8. The remote reader is never matched to the local writer, since nobody is signalling about it anymore

Pros:

• Removes the race condition

Cons:

• Failure in sending the AddWriter (or reader) command to Discovery no longer produces a direct error to user in DataWriter creation:
  • because the command is now sent in DP event loop (instead of the CreateDataWriter function), there's no longer a direct result value to return to the user in case of failure
  • instead, now an error-level log entry is created

[jhelovuo]

Fix released in 0.11.8