Fix unsound Clone and undefined behavior in self-referential Buf variants

[sebschrader]

TemplateBuf and ByteTemplate are implemented as self-referential structs, but their current implementation is unsound and contains undefined behavior.

According to my analysis the following issues exists:

• The derived Clone implementations by the compiler are unsound, as they copy the static reference by value, causing all kinds of memory issues (panics due to memory issues caused my investigation.)
• As field order of structs determines the drop order, the underlying String or Vec<u8> will be dropped before the reference, this UB according to my understanding, as there will be dangling reference.
• String and Vec<u8> are implemented using core::ptr::Unique. As such all references to such a type, are invalidated, if such a type is moved. See Self-referential types for fun and profit by @hniksic for details

This PR tries to address these issues.

• I've included a small test to reproduce the first issue.
• The fixes for the first two points are rather self-explanatory.
• For the last issue I've implemented the aliasable::String and aliasable::Bytes types instead of pulling in an extra dependency like the aliasable crate.
• I've checked my changes, by running the tests with miri. It passes but requires tree-borrows (MIRIFLAGS="-Zmiri-tree-borrows").

[de-vri-es]

Eep, thank you for reporting this and opening a PR! I can't believe I added that Clone implementation 😱

Maybe we can can use Pin<String> / Pin<Vec<u8>> instead of more unsafe code with aliasable. However, I think we should push the fix for the Clone impl and the destructor order asap.

The last part of the fix is probably less likely to cause actual runtime problems. I still think they are super important to fix, but I would like to see if we can do it while reducing unsafe code instead of increasing it.

I will yank the unsound versions once fixes are released!

[de-vri-es]

I merged the first three commits and released them as 0.3.6. I think that gives a bit of breathing room to look at the remaining issue of references to heap allocations being invalidated when String and Vec<u8> are moved.

[de-vri-es]

I've opened #30 with a different approach to solving the aliasing problem. Rather than swapping Vec with a custom implementation, that approach wraps the Template that holds the references in MaybeUninit. More details available at that PR.

The main motivation for the alternative approach is that it's less extra unsafe code compared to aliasable::Byte/String. It also doesn't need extra miri flags to pass the tests.

[de-vri-es]

Merging without the last commit.

Thanks again! This was a really important fix 😬

Released v0.3.7 with all the fixes and yanked all the unsound version.

[sebschrader]

I've opened #30 with a different approach to solving the aliasing problem. Rather than swapping Vec with a custom implementation, that approach wraps the Template that holds the references in MaybeUninit. More details available at that PR.

The main motivation for the alternative approach is that it's less extra unsafe code compared to aliasable::Byte/String. It also doesn't need extra miri flags to pass the tests.

I'm not familiar enough with aliasing guarantees/details around MaybeUnit to judge this approach.

Thank you for your quick action and your work in general too!