First preparations for release 0.4.0

[sosthene-nitrokey]

• Remove cbor feature
• Remove Deref impl to heapless and replace it with a impl of Deref<Target = [u8]>
• Remove try_from(f: impl FnOnce(&mut [u8]) -> Result<usize, ()> API
  AFAIK this is only used in trussed-utils to serialize cbor, which can be done through dedicated cbor-smol methods instead.
• Remove insert_slice_at
  This is only used in fido-authenticator to add data to the beginning of the buffer. This can easily be made in 3 lines of code without using internal APIs.
• Add From<Bytes<N>> for Vec<u8, N> and vice-versa
• Make default features required (so that we can feature-flag the heapless parts of the public API in the future).
• Renamed resize_default to resize_zero since we know that Default means Zero here.

[robin-nitrokey]

Can you explain your plans for the default feature? AFAIS, your implementation only exposes heapless::Vec via the From implementations, so I think we could already put them behind a heapless-0.8 feature flag.

[sosthene-nitrokey]

That way we don't have to do this now, if we want in the feature we can add a default-enabled heapless-0.8 feature flag and remove the requirement for the default feature flag.

But if before that we realize that AsMut is required, we can just do another release where we add it, and drop the idea of being able to bump heapless without a major version bump.

[robin-nitrokey]

I would introduce the heapless-0.8 feature directly because it would make it explicit which crates actually use the conversions. (I suspect it will only be one or two.) And I don’t think it makes a difference for a potential update to heapless 0.9. Best case we can just add a feature for it, or we need a breaking release anyway where we can also change the features. But it’s not a big issue so I’m also fine with the default approach.

[sosthene-nitrokey]

I prefer the default approach so that it doesn't require us to document features we might never need to use.

[robin-nitrokey]

Just one final observation from my side: If we use the default approach and the migrate from heapless 0.8 to 0.9, we need to update all crates using heapless-bytes to get rid of heapless 0.8. If we would directly use the feature, we would only need to update the crates that enabled the feature.

[sosthene-nitrokey]

That's a good point.

I'll move to directly have the heapless-0.8 feature then.