Remove the Vec representation

[SabrinaJewson]

Bytes currently has both a “Vec” and “shared” representation, lazily upgrading the former to the latter. I believe that originally, the “Vec” representation allowed for excess capacity, but now it only works when len == cap. Given that it only saves one heap allocation, which is probably made anyway most of the time (it’s made whenever one does .split, .truncate, .clone etc), I would like to know how worth it it actually is.

The main benefit of removing it would probably be the removal of atomics, meaning it might have a bigger performance impact on ARM. But I don’t have an ARM machine, so if someone could run some benchmarks (Hyper or Tonic or something) on ARM – ideally multithreaded ones – that would be appreciated.

Maybe there’s a use case for this optimization I’m missing. I find that pretty rare to be using Box<[u8]> so I’m somewhat doubtful.

---

This PR is very much unfinished, I just creäted for initial feedback on the idea, and benchmarking purposes.

[Darksonn]

I'm skeptical that replacing a load-acquire with a normal load is worth adding extra allocations for the case where a Bytes is created and used but never cloned. My gut feeling is that there are plenty of people who create a Bytes without ever cloning it.