Support alloc-free operation

[00imvj00]

Support alloc-free operation

[MathiasKoch]

@vincentdephily Did you manage to make any further progress on this? It is something i would really like to see, as this issue is the only reason why all my crates built on top of this requires alloc.. MqttClient, Aws IoT libraries etc.

Anything i can do to help?

I am aiming towards a completely heapless stack, as to know at compile-time i wont run into OOM situations. 100% uptime is crucial in our application.

[vincentdephily]

I haven't touched this in a while and it isn't on my TODO, but I'm happy to help you implement this.

As I said, some of the work has already been done, by starting to use the Buf(Mut) trait instead of the Bytes(Mut) struct wherever possible. From there, it's basically a matter of 1) passing a stack-allocated buffer such as &[u8] to encode() and decode() and see/fix what breaks 2) switch the crate to no_alloc and see/fix what breaks.

encode() is further along than decode(), and I believe you can already give a stack-allocated &[u8] to encode(), and I think that the rest of the encode is stack-only as well. If I didn't break/remove any of the buf.remaining_mut() checks, this means encode() is already no-alloc.

Fixing the breakage will probably involve giving up on some of Bytes's utility functions. It'll be less elegant but I imagine it's straightforward (Famous Last Words).

Don't hesistate to open a PR before it's ready for merging, if you get stuck somewhere. I'm also reachable on Matrix as @moltonel:matrix.org, and hang out on the Rust channels.

[MathiasKoch]

Awesome!
I can confirm that after merging #28, encode() is indeed fully usable in no_alloc.. On to decode() it is.. We will give it a shot, and might give you a ping along the way on Matrix..

How about Strings and Vecs in payload, topic-name etc? Do you guys have preferences, or should we go with something like heapless in no_alloc?