swift: add core

[fsuc]

What's new

Add a implementation of the Core which uses a MQTTClient and a TelemetryClient to perform MQTT operations with traces.

---

How to test

1. Clone the its-client project and check out the branch under review
2. Run a local OpenTelemetry collector with a http endpoint on port 4318:

    $ docker container run \
         --rm \
         -p 16686:16686 \
         -p 4318:4318 \
         jaegertracing/all-in-one:1.58

3. Run the test CoreTests.message_sent_to_subscribed_topic_should_be_received_and_create_linked_span:

   swift test --filter CoreTests.message_sent_to_subscribed_topic_should_be_received_and_create_linked_span   

   Expected result: Check on the Jaeger UI (on http://localhost:16686/) that that 1 producer span and 1 consumer span which references the producer have been created.
4. Run the test CoreTests.message_sent_with_error_should_create_span_with_error:

   swift test --filter CoreTests.message_sent_with_error_should_create_span_with_error   

   Expected result: Check on the Jaeger UI (on http://localhost:16686/) that 1 producer span has been created with an error.
5. Run the test CoreTests.send_message_without_telemetry_should_not_create_span:

   swift test --filter CoreTests.send_message_without_telemetry_should_not_create_span   

   Expected result: Check on the Jaeger UI (on http://localhost:16686/) that no span have been created.

Closes #284

[ymorin-orange]

If I understand correctly, this guard ensures that we can only unsubscribe (but there is the same guard on the subscribe) when the MQTT client is actually connected.

This has too implications, both not very pleasant:

1. the user of the SDK may not be aware that the MQTT client got disconnected, so they will get an exception; and even if they checked whether the MQTT client was connected before unsubscribing, this is both tedious and not race-free;
2. the MQTT client does not automatically re-subscribe on its own, and the user of the SDK has to track subscriptions on their own; since they have no way of knowing if/when the MQTT client gets dis/connected, they have no way to know if/when they have to re-subscribe to their topics of interest.

What would be a better solution is to actually keep the list of subscriptions as a "private member" in the MQTT client object, and allow the user of the SDK to manipulate that list at will (by way of calling subscribe() and unsibscribe()). Then when the MQTT client gets connected, it requests those subscriptions to the broker.

[fsuc]

For the first point the library does the same : it launches an exception if not connected so it would be the same result without the guard for all the operations.
I plan to manage the disconnection later because there are two main options:

1. just trigger a disconnection event for the client. The client must stop publishing messages or update subscriptions and handle a new connection/subscriptions depending its network status (network is on -> reconnect) or a retry mechanism if the disconnection is not related to the mobile network.
2. Handle this internally with a reconnection mechanism that can connect and resume the subscriptions. In this case, we need to choose the behavior when a message is sent when reconnecting (skip, save to send later ?). This solution is easy to use but opaque and can be related to the use case of the client regarding the behaviors when reconnecting.

[fsuc]

Option retained : 2 for a future PR.
Update subscriptions list and skip published message when reconnecting.

[ymorin-orange]

• Code peer-reviewed
  • Comments to be addressed as evolutions, so in future PRs.
• Tests OK