rlp: add ArrayVec impls

[vorot93]

Useful for limited-size lists.

[dvdplm]

A few tests would be good: normal, zero-length, beyond capacity.

[dvdplm]

I think you missed adding this feature to Cargo.toml.

[vorot93]

Optional dependencies are features in themselves.

[dvdplm]

TIL! 👍

(I'd still want all features in the Cargo.toml, preferably documented, for discoverability reasons)

[dvdplm]

I don't want to be naysayer but this is a slippery slope here; ArrayVec yes but SmallVec, TinyVec, ThinVec no? It would be good to have a concrete use-case and a proper motivation for why ArrayVec will be useful long-term.

[vorot93]

My concrete use case is for Neighbours discv4 packet:

https://github.com/ethereum/devp2p/blob/master/discv4.md#neighbors-packet-0x04

It is a given that the reply is a limited-size vec of up to 16 elements. Would be nice to embed this property in the type system, but for that I need RLP to support any limited-size vec implementation. I suppose ArrayVec is the most popular out there, so I just went with that.

[dvdplm]

Thank you for the motivation, it's much clearer now. I'm still hesitant. Even if it's an optional dependency, it still needs maintenance. The future of arrayvec is a bit unclear, as the author puts it "Const generics is arrayvec 2.0", so I think this would be useful mostly until const generics is ready?

[ordian]

@vorot93 is this PR still relevant now that we have Bytes impl?

[vorot93]

@ordian Yes! This PR is about limited collections of items, not byte arrays.

At the same time, however, I can see @dvdplm 's reasoning that eventually ArrayVec may be made obsolete by const generics.

[ordian]

I see, I thought the reason was to avoid allocations which, it seems, you were able to achieve with bytes.
I share the same opinion as @dvdplm and hesitant to merge this as min const generics are targeting stabilization in february.
For now you can use a newtype wrapper for ArrayVec.