Initial implementation of `up-streamer-rust`

[PLeVasseur]

Intro

Initial implementation of up-streamer-rust to connect point-to-point messages across any UTransport implementation, i.e.

• Notification
• Request
• Response

The implementation of handling Publish messages will come in a second PR.

Background

Hey there :wave:

Based on @stevenhartley's stellar design, I reworked the in-progress first PR I had.

Looking for any feedback you may have :slightly_smiling_face:

Addresses #3

A rework of #7 in which UTransport is thread-safe

Also rework of #9, since in this one we used dedicated tasks for output onto a transport when forwarding for efficiency and consistent sequencing.

TODO

• [x] Rebase onto https://github.com/eclipse-uprotocol/up-rust/pull/79 to ensure still functional
• [x] Get integration tests setup to ensure in-order delivery of all sent messages
• [x] Troubleshoot why messages are being lost when benchmarking throughput
• [x] Refactored integration-test-utils to allow us to orchestrate adding and deleting rules on the fly
• [x] dynamic adding and removing routes integration tests: local, remote_a -> local, remote_a, remote_b -> local, remote_b (may have to refactor integration test utils)
• [x] Consider if / how to refactor book-keeping of routes
• [x] update sequence diagram to reflect current state
• [x] Update to latest up-rust

Performance

Seems to improve performance over #9 and in line with #7

Stats

	#7 Non-Thread-Safe: With Channels # of messages received in 1 second	#8 Thread-Safe: Straightforward Implementation # of messages received in 1 second	#9 (this PR) Thread-Safe: Utilizing Async Task for Sender # of messages received in 1 second
Avg	5067	3560.6	4966.5
StdDev	79.14543575	49.19846429	80.11554156

[PLeVasseur]

Hi @sophokles73, @AnotherDaniel, @stevenhartley, @Mallets, @evshary --

Bringing the initial version out of draft. Ready for some feedback :slightly_smiling_face:

[PLeVasseur]

I haven't taken a deeper look, but your implementation doesn't depend on any up-client library now, right?

That's right. I have abstracted away completely from any specific up-client-foo-rust.

[PLeVasseur]

I find the code very hard to read and understand due to the lack of comments. In particular, it is still unclear to me why you need that many HashMaps for keeping all sorts of references and counters.

Started to simplify this a bit.

My gut feeling is that you could replace at least the TransportForwarder{Count} maps with just Arcs and tha fact that the forwarders will cease to exist once all Senders have gone out of scope ...

Yeah, I agree that this would work, did this part so far.

[PLeVasseur]

I find the code very hard to read and understand due to the lack of comments. In particular, it is still unclear to me why you need that many HashMaps for keeping all sorts of references and counters.

So, I think some of this complexity is inevitable. Given that, I tried to more clearly divide the responsibility for managing the TransportForwarders and ForwardingListeners.

Greatly looking forward to your feedback :slightly_smiling_face:

[sophokles73]

@PLeVasseur do you want to squash the commits before I merge this?

[PLeVasseur]

@PLeVasseur do you want to squash the commits before I merge this?

Yes, I will squash the commits. Will ping you when done

[PLeVasseur]

Okay @sophokles73 -- I squashed the commits