fix: disconnect cleanly from local MQTT broker in tedge connect

[reubenmiller]

Proposed changes

Send MQTT DISCONNECT on local MQTT connections (in normal operation) in the tedge connect and tedge reconnect commands.

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

• tedge connect c8y does not cleanly close the local MQTT connection #3024

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

[reubenmiller]

First commit is to add the system test (Check absence of OpenSSL Error messages #3024) which should fail, and the second commit will be to fix the bug.

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
487	0	2	487	100	1h28m7.398575s

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 48 lines in your changes missing coverage. Please review.

Project coverage is 78.0%. Comparing base (d575685) to head (19e320d).
Report is 1 commits behind head on main.

Additional details and impacted files

Files	Coverage Δ
crates/core/tedge/src/cli/connect/jwt_token.rs	39.8% <0.0%> (-4.8%)	⬇️
crates/core/tedge/src/cli/connect/command.rs	0.0% <0.0%> (ø)

... and 8 files with indirect coverage changes

[gligorisaev]

The added test step is doing what is intended for

[gligorisaev]

The added test was reviewed and it is passing

[Bravo555]

Confirming that this patch fixes the problem.
Simple and sufficient for now, but another example of rumqttc API being a bit too verbose for our use case here. For a more elegant fix in the future, we should either use our mqtt-channel or create a wrapper over rumqttc::Client that at minimum provides a disconnect on drop.

[albinsuresh]

LGTM