## Provisioning Flow

The device must have a valid `Provisioning Token`.
This token may be shared between multiple devices and may not have any identifiying information embedded.
It sends this token in an `init_provisioning` operation to create a provisioning operation in the cloud.
An operator in the cloud must approve this operation.
Then the device can use `complete_provisioning` to obtain a `Registration Token`.
This token is not shared and information about the device (its ID) is embedded there.
These tokens may have expiration and may be automatically refreshed using a `refresh` operation.

## Features

### Supported features

#### Device Provisioning Service
* Interactive flow for obtaining Registration Tokens with provided Provisioning Token
* Setting desired Device ID for the Registration Token
#### Device Registration Service
* Registration of devices with Registration Tokens
#### Ingress
* Asynchronously send messages
    * `ConnectionWithDataUnit::send` (and implicit `ConnectionWithDataUnit::drop`) are blocking until the message is persisted to SQLite store.
* Storing messages and resending any unacknowledged messages with at least once delivery guarantee.
* Storing Provisioning and Registration Tokens.
* Automatic refreshing of Registration Tokens
* Automatic reregistration on expired registrations

### Unsupported features

#### Device Provisioning Service
* Creation of tokens with expiration date
#### Device Registration Service
* Registration with mTLS
#### Ingress
* Custom message properties
* Setting maximum stored messages
* Sanitation of loaded messages -- currently a single malformed message can break everything (IoT Hub will disconnect upon receive)
* Chunking
* Compression
#### Device Management Service
* Usage of device twins
* Receiving C2D messages
#### Data Gateway
* Sending data

### Needed non-features
* Resiliency for API calls
* Resiliency for backup threads - restarts on panics
* Better algorithm for deciding when to refresh registration token
* Cross-compilation

## Operational Aspects

* Device ID is obtained and saved in Registration Token. If the Device ID is supposed to be changed the device needs a new token. All messages that were persisted will be sent with the Device ID configured when the data is sent, not when publish was called.

## Improvements to Be Done

* Better decision between telemetry and file-upload
* Better handling of twin patches -- allow setting of twins and not just pass to cloud whatever the user sends (that ends up with a merge including null handling
* First-class logging, metrics