Refactor the c8y remote access plugin to use the c8y auth proxy

[jarhodes314]

Proposed changes

This PR adds support for websockets to the auth proxy, and modifies the c8y remote access plugin to connect via the auth proxy, rather than making a direct connection to c8y.

There are still a few TODOs in the code, but the broad shape of the changes are in place and the happy path works for me testing locally.

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

• Refactor the c8y remote access plugin to use the c8y auth proxy. #2591

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

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
381	0	3	381	100	51m55.441s

[codecov]

Codecov Report

Attention: 76 lines in your changes are missing coverage. Please review.

Comparison is base (fb82765) 75.8% compared to head (845480e) 75.9%.
Report is 4 commits behind head on main.

Additional details and impacted files

Files	Coverage Δ
crates/extensions/c8y_auth_proxy/src/url.rs	80.8% <ø> (+1.1%)	⬆️
plugins/c8y_remote_access_plugin/src/proxy.rs	34.6% <0.0%> (+0.4%)	⬆️
crates/extensions/c8y_auth_proxy/src/actor.rs	0.0% <0.0%> (ø)
plugins/c8y_remote_access_plugin/src/lib.rs	20.8% <0.0%> (-1.5%)	⬇️
crates/extensions/c8y_auth_proxy/src/server.rs	89.5% <89.2%> (+0.6%)	⬆️

... and 4 files with indirect coverage changes

[albinsuresh]

I'm no expert of either the axum or the tungstenite crates. But the connection/conversion logic looked sensible. Just spotted one minor bug in the conversion task error handler.

[albinsuresh]

Query: Since this whole function doesn't return anything even while detecting one of the above failures, how would the wrapping server react? I'm assuming it would continue functioning without the proxying capability. Wouldn't it be better to propagate these errors so that the server can choose to shutdown/panic, with the hope of restarting without that issue?

This might be out of scope for this PR specifically, as it's related to our general strategy on how we handle partial failures of a single component, in a multi-component process.

[jarhodes314]

I'm not sure exactly what axum does internally, but my belief is that this is a separate task spawned when we call ws.on_upgrade. In any case, it only affects the current connection, nothing else, and I believe this is the most desirable behaviour. If we were talking over HTTP, this is a point at which I would give up and respond with 500 Internal Server Error to the current request, but I wouldn't want the server to stop running, particularly as the issue at this point is quite likely one with Cumulocity.

[albinsuresh]

Looks like a block of code repeated in the previous test as well, that can be moved to a test setup function that takes the Router definition as an argument.

[didier-wenzek]

Approved. Working as expected and nicely done.