fix: increase max packet size for built-in bridge

[jarhodes314]

Proposed changes

• Increase the max packet size of the built-in bridge to the same value as is used by tedge mqtt pub
• Document the feature flag for the built-in bridge
• Refactor the logic from fix: built-in MQTT bridge handling of QoS 0 messages published to the cloud topic #3028

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

• Built in mqtt bridge restricted to 10240 bytes #3056

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 90.90909% with 1 line in your changes missing coverage. Please review.

Project coverage is 78.7%. Comparing base (79fb63c) to head (5cfb663).
Report is 6 commits behind head on main.

Files	Patch %	Lines
crates/extensions/tedge_mqtt_bridge/src/lib.rs	87.5%	0 Missing and 1 partial ⚠️

Additional details and impacted files

Files	Coverage Δ
.../tedge_config/src/tedge_config_cli/tedge_config.rs	73.7% <100.0%> (+<0.1%)	⬆️
crates/extensions/tedge_mqtt_bridge/src/lib.rs	89.3% <87.5%> (+1.0%)	⬆️

... and 4 files with indirect coverage changes

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
491	0	2	491	100	1h33m30.187594999s

[albinsuresh]

Looks like we have some inconsistency with packet sizes used across the project.

1. In mqtt_channel::config::Config: 1024 * 1024
2. In bridge::common_mosquitto_config::CommonMosquittoConfig: 256 * 1024 * 1024 - 1
3. In tedge::cli::mqtt::MAX_PACKET_SIZE: 10 * 1024 * 1024

Any reason why you chose the 3rd option and not the second one, keeping it consistent with the existing bridge config?

[jarhodes314]

I didn't realise that mosquitto used a completely different name for the configuration, so didn't notice it. I'll change this to be consistent with the existing bridge.

[albinsuresh]

Can this pkid = 0 case be covered with a unit test?

[jarhodes314]

Not easily. In an ideal world, we would have some deterministic tests where we control the broker we connect to directly, so we can send QoS 0 messages. This would also shore up the existing integration tests, which have to flood the bridge with thousands of messages before disconnecting to reproduce the desired behaviour.

I think this might be worth investigating in a time-boxed manner, but I'll create a separate ticket for it.

[didier-wenzek]

Can this pkid = 0 case be covered with a unit test?

This is tested by the system test "Support publishing QoS 0 messages to c8y topic #2960".

Sure, this test is not deterministic (as messages with QoS 0 might not be delivered), but I think that is enough.

[albinsuresh]

LGTM

The limit was expected to be 256 MiB

[didier-wenzek]

Approved