Build zero-copy `UTransport`

## Why a zero-copy transport for uProtocol?

* It's very common in Advanced Driver-Assistance Systems (ADAS) / Automated Driving (AD) systems to have large messages which are being sent around, including large camera images and point cloud data from LIDARs
* It's becoming common in automotive systems to have a gateway concept where inter-device communication flows into each device's gateway over a different transport (e.g. [SOME/IP](https://some-ip.com/), [CAN](http://esd.cs.ucr.edu/webres/can20.pdf)) and is then copied into shared-memory to allow [zero-copy](https://en.wikipedia.org/wiki/Zero-copy) publishes to consumers
* By providing a zero-copy `UTransport` we open up uProtocol to the ADAS / AD domains and wider adoption in OEMs / integrators which desire this functionality in a gateway

## Main goals

Implement a _zero-copy_ [`UTransport`](https://github.com/eclipse-uprotocol/up-spec/tree/main/up-l1) where the `UMessage` is not _copied_ from sender to receiver but is _passed on_ by means of a shared memory reference only (or equivalent mechanism).

* In a first step, use the existing [Protobuf](https://protobuf.dev/) encoding of `UMessage` to serialize the message to an (opaque) byte array which can then be passed on by means of a shared memory reference.
* In a second step, figure out what it would take to avoid serialization and deserialization of `UMessage` altogether, even across programming languages. This will most certainly require the sender and receiver implementations to have the same understanding of how memory is laid out for a particular data structure.
* In a third step, implement the zero-copy, no-serialization approach.

### Constraints

* Use [iceoryx2](https://github.com/eclipse-iceoryx/iceoryx2) to implement the zero-copy transport, as it is a forward-looking solution and is headed for ASIL-D safety-qualification

## Desired outcomes

* A Rust based UTransport implementation (`up-transport-iceoryx2-rust` crate) which can be published to [crates.io](https://crates.io/).

### Extra integration into uProtocol ecosystem

* Show integration of `up-transport-iceoryx2-rust` into `up-streamer-rust` [reference implementation](https://github.com/eclipse-uprotocol/up-streamer-rust/tree/main/configurable-streamer)
* Attempt to use the [Eclipse Zenoh](https://github.com/eclipse-zenoh/zenoh) shared-memory transport option
* Interesting to ask: Why did Eclipse Zenoh choose not to use iceoryx2?
* Create a C-based implementation of the zero-copy transport (`up-transport-iceoryx2-c`)
* Show interoperability between `up-transport-iceoryx2-rust` and `up-transport-iceoryx-c`
* Use Gherkin feature files to show compatibility as is being done for `up-rust` tests

## Additional resources

### Eclipse Foundation

* [Eclipse Contributor Agreement](https://www.eclipse.org/legal/eca/)
* To actually sign it go [here](https://accounts.eclipse.org/user/eca)

### Rust

#### Mindset

* [Rust in 2025: Targeting foundational software](https://smallcultfollowing.com/babysteps/blog/2025/03/10/rust-2025-intro/)

#### Typical community suggestions

* [The Rust Programming Language](https://rust-book.cs.brown.edu/)
* [Rust by Example](https://doc.rust-lang.org/rust-by-example/)
* [rustlings](https://github.com/rust-lang/rustlings)

#### Things also sometimes recommended, maybe more niche

* [Learn Rust With Entirely Too Many Linked Lists](https://rust-unofficial.github.io/too-many-lists/)
* [Learn Rust the Dangerous Way](https://cliffle.com/p/dangerust/)

### iceoryx2

How does iceoryx2 allow for zero-copy shared memory understanding of memory layout between languages? Doesn't each language have different memory layouts and representation?

True! So in the iceoryx ecosystem they have libraries for languages which allow a common understanding:

* Rust: [iceoryx2_bb_container](https://crates.io/crates/iceoryx2-bb-container) - link to [docs](https://docs.rs/iceoryx2-bb-container/0.6.1/iceoryx2_bb_container/)
* C++: [iceoryx hoofs](https://github.com/eclipse-iceoryx/iceoryx/tree/main/iceoryx_hoofs)

#### Getting started with iceoryx2

* Great to start with the [docs](https://docs.rs/iceoryx2/0.6.1/iceoryx2/) on crates.io!
* Consider building their examples and experimenting with them

## Eclipse uProtocol - Topology

There's a somewhat outdated, but still conceptually relevant diagram in the [uProtocol Roadmap](https://docs.google.com/document/d/1KIz5Jdg6uz7Cd31SElPn8oXyGyYRt_y0YFChX7FfKNg/edit?usp=sharing).

Generally speaking, unless constraints would prevent otherwise, within a single logical or physical system, a zero-copy / shared memory transport should be used (the black lines in the diagram). Between logical or physical systems, other mechanisms are used as appropriate.

The uStreamer is used as a protocol bridging library and service to allow the transition to/from different underlying protocols.


### `UTransport`

* Here's a [link](https://github.com/eclipse-uprotocol/up-rust/blob/72b6507e3b4fe0f0b3a873307a63e3d9118c130d/src/utransport.rs#L177) to the `up-rust` `UTransport` trait.
* There are existing implementations
* [`up-transport-mqtt5-rust`](https://github.com/eclipse-uprotocol/up-transport-mqtt5-rust/blob/b96072917e83fbefbaca6f93bca0a4b2a5060245/src/transport.rs#L49)
* [`up-transport-zenoh-rust`](https://github.com/eclipse-uprotocol/up-transport-zenoh-rust/blob/6eec892323db4bd830bd67cd2aad5c41e2d13e05/src/utransport.rs#L121)
* [`up-transport-vsomeip-rust`](https://github.com/eclipse-uprotocol/up-transport-vsomeip-rust/blob/cb0151394966a4ed5047b246da62c4a9352a90a4/up-transport-vsomeip/src/transport.rs#L29) - the most complicated since it involved interop between C++ <=> Rust, so don't start here 🙂

Start by reading the up-rust UTransport trait in src/utransport.rs and comparing the linked MQTT5, Zenoh, and vsomeip implementations. Then build and experiment with the iceoryx2 examples and determine the scope of the up-transport-iceoryx2-rust crate. Done requires a publishable Rust transport plus the requested streamer integration and interoperability evidence.

Written by the indexing model from the issue text.