TODO

• add documentation wrote a reference doc and the draft of a user guide, subject to change because details related to the UNIX socket setup are still being hashed out
• resolve current hacks and workarounds in places where we assume private key always comes from a file there were some hacks but they're now removed
• Add new cargo feature called "cryptoki" where all of the dependencies related to the cryptoki are hidden below it (and the feature is not activated by default). Configuration can be marked as hidden until configuration names are agreed upon

Follow-up items

• return a config error before connecting (i.e. at the config parsing stage) if device.cryptoki.enable is true, but module path is not set
• include the HSM configuration in the tedge connect summary
• refactor TLS configuration setup 2c27e33
• upstream libloading musl patch
• extend support to aws and azure clouds
• testing: use softHSM for mocking HSMs and testing of the signing flow

Proposed changes

Allow the use of Hardware Security Modules for MQTT client authentication when using c8y cloud.

We add the following config settings:

     device.cryptoki.enable  Use a Hardware Security Module for authenticating the MQTT connection with the cloud.  When set to true, `key_path` option is ignored as PKCS#11 module is used for signing. 
                             Examples: true, false
device.cryptoki.module_path  A path to the PKCS#11 module used for interaction with the HSM. 
                             Example: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
        device.cryptoki.pin  Pin value for logging into the HSM. 
                             Example: 123456
     device.cryptoki.serial  A serial number of a Personal Identity Verification (PIV) device to be used.  Necessary if two or more modules are connected. 
                             Example: 123456789

which are then used for configuring HSM authentication parameters.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

#3363

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments