feat: make alloc optional

[GabrielDertoni]

Currently the no_std support for the crate still depends on alloc. However, this is only required for Bytes and BytesMut data structures and not Buf and BufMut traits or its other impls. This PR makes alloc optional in order to make the crate more suitable for embedded environments.

The main benefit of this change is beeing able to depend only on the Buf and BufMut traits, which is very usefull not only to embedded environments, but also for other crates that would like to use those traits but don't need Bytes and BytesMut. I think this would be a good thing, since it encorages everyone to use bytes and reduce the number of parallel implementations of this same concept.

As an example usecase, rust-mavlink had to pretty much reimplement Buf and BufMut because they don't want a hard dependency on alloc.

This PR adds a alloc default feature that can be disabled if not required. However, maybe it would be better to add a embedded or no_alloc feature instead, so that it doesn't break any code that depends on bytes. Please let me know what you think of this change.

[Darksonn]

Sorry, but this is a breaking change. Code that previously compiled with no features enabled would break. Unfortunately, we also cannot add a no_alloc feature because features must be additive.

[GabrielDertoni]

Oh, I see. Would it be possible to maybe create a different crate (say we name it bytes-buf) that has only the Buf and BufMut traits implemented for builtin rust types? This new crate would have an alloc feature. Then bytes could depend on bytes-buf with the alloc feature and reexport the traits. Just an idea, don't konw if it's too much of a hassle.

[taiki-e]

See #479 for previous discussions.

[maximeborges]

Can we finally get that in? Every year I'm starting a new project that would benefit from using bytes in no_std & no_alloc environment.

From #479 (comment)

The main problem is that we recently released v1 and don't want to release v2 right away.

I would assume that more than 3 years after v1 release we can allow a major update that would allow more people to finally use this lib.

[Darksonn]

The only possible way that this is happening is that we accept the minor breakage. We will not make a bytes v2.

[maximeborges]

So what's your opinion on that, in regard to #480 (comment) ?
I've started modifying the lib I needed to use byte instead but the difference in usage might not be a good fit for any library currently using bytes.

[Darksonn]

I do not really know how many libraries out there specify default-features = false for bytes. It's hard to say whether it's acceptable without knowing that.

[Darksonn]

Sorry, I failed to respond to this. We already have std as a default feature, so it's extremely likely that there are users of default-features = false out there. So that solution is not possible.