fix: use MQTT as well as HTTP host to determine possible tenant url

[jarhodes314]

Proposed changes

Determine whether URLs are Cumulocity URLs based on both the HTTP and MQTT host, not just the HTTP host.

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

• Cumulocity IoT urls fail to download when using custom domain name #2969

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

[codecov]

Codecov Report

Attention: Patch coverage is 87.30159% with 8 lines in your changes missing coverage. Please review.

Project coverage is 78.0%. Comparing base (4a805f3) to head (1c68fab).
Report is 16 commits behind head on main.

Additional details and impacted files

Files	Coverage Δ
...rates/extensions/c8y_firmware_manager/src/tests.rs	92.6% <100.0%> (+<0.1%)	⬆️
crates/extensions/c8y_http_proxy/src/actor.rs	54.1% <100.0%> (+0.4%)	⬆️
crates/extensions/c8y_http_proxy/src/tests.rs	93.4% <100.0%> (+<0.1%)	⬆️
crates/extensions/c8y_mapper_ext/src/converter.rs	84.1% <100.0%> (+<0.1%)	⬆️
...es/extensions/c8y_mapper_ext/src/operations/mod.rs	88.0% <100.0%> (+<0.1%)	⬆️
crates/extensions/c8y_mapper_ext/src/tests.rs	92.7% <100.0%> (+<0.1%)	⬆️
crates/core/c8y_api/src/http_proxy.rs	75.5% <96.7%> (+2.9%)	⬆️
crates/extensions/c8y_mapper_ext/src/config.rs	48.5% <66.6%> (+0.2%)	⬆️
...ates/extensions/c8y_firmware_manager/src/config.rs	60.7% <50.0%> (-1.1%)	⬇️
crates/extensions/c8y_http_proxy/src/lib.rs	52.9% <0.0%> (-2.2%)	⬇️

... and 4 files with indirect coverage changes

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
476	0	3	476	100	1h13m3.111446s

[albinsuresh]

The logic is pretty straightforward for those having separate c8y.http and c8y.mqtt settings, and implemented as described in the ticket.

But, my understanding was that the end user sometimes may not even be aware of the internal URLs and they are only exposed to the external custom domains. So, they probably wouldn't even know that they need to configure both settings separately. This is the reason why querying the https://your.custom.domain/tenant/loginOptions endpoint was proposed as a better fix approach in #2804.

But, if it is guaranteed that custom domain users would configure their tedge like this with both the settings, then I'm happy to approve this PR once the tests pass (a rebase required).

[reubenmiller]

The logic is pretty straightforward for those having separate c8y.http and c8y.mqtt settings, and implemented as described in the ticket.

But, my understanding was that the end user sometimes may not even be aware of the internal URLs and they are only exposed to the external custom domains. So, they probably wouldn't even know that they need to configure both settings separately. This is the reason why querying the https://your.custom.domain/tenant/loginOptions endpoint was proposed as a better fix approach in #2804.

But, if it is guaranteed that custom domain users would configure their tedge like this with both the settings, then I'm happy to approve this PR once the tests pass (a rebase required).

We can address the "easy of configuration" aspect to a separate PR. This PR is purely focusing on the case where the user knows that they have to use two separate URLs for the MQTT and HTTP traffic, however thin-edge.io may receive binaries either using the internal URL OR the custom domain name (as the user can manually use the custom domain when uploading binaries to their tenant).

[didier-wenzek]

Approved

[didier-wenzek]

There is a flaky test (unrelated to this PR) failing the merge queue :

test tests::test_cli_pub_basic::none_expects ... FAILED

failures:

---- tests::test_cli_pub_basic::none_expects stdout ----
thread 'tests::test_cli_pub_basic::none_expects' panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/assert_cmd-2.0.13/src/output.rs:65:25:
command="/home/runner/work/thin-edge.io/thin-edge.io/target/llvm-cov-target/debug/tedge" "--config-dir" "/tmp/.tmp5EPpVm" "mqtt" "pub" "topic" "message"
code=1
stdout=""
stderr=
ERROR: the message has not been published
Error: failed to publish the message \"message\" on the topic \"topic\" with QoS \"AtMostOnce\".

Caused by:
    0: I/O: connection closed by peer
    1: connection closed by peer