Document relationship to Project Safe Transmute

[jswrenn]

@briansmith, author of ring, wrote the following:

These users are extremely wary of taking external dependencies, and only take dependencies when they absolutely need to or when they have a high degree of trust in an external software artifact.

This describes me well. I considered multiple times using zerocopy and extending zerocopy. Pulling it out of Fuchsia and making accessible here on GitHub was a big step towards that. But then the formation of the "safe transmute" working group in the rust-lang organization made it seem like it would be just better to wait until the most important functionality is in libstd and guaranteed by the language/lib spec more explicitly.

[...]

Ultimately, I think people just would rather have as much of the functinoality w.r.t. transmuting and casting in the standard library as possible. I think if this is seen as a prototype that helps that happen, more people will be eager to adopt it.

It is problematic for both Project Safe Transmute and crates like zerocopy that the announcement of Project Safe Transmute has had a chilling effect on the adoption of safer abstractions over transmutation. Project Safe Transmute relies on the adoption of these third-party crates to inform its design process. Moreover, it is unlikely that the work of Project Safe Transmute will supplant the need for these third-party crates.

The current plan of record for Project Safe Transmute will produce a low-level feature which supports the soundness analysis currently implemented by our custom derives. Eventually, crates like zerocopy will be able to transparently replace their bespoke soundness analyses with the one provided by Project Safe Transmute.

However, Project Safe Transmute won't replace most of the higher-level abstractions in zerocopy itself. For the foreseeable future, crates like zerocopy will still be required in order to provide these higher-level abstractions on top of the building block provided by Project Safe Transmute. For many higher-level use cases, Project Safe Transmute will provide the foundation on which users can prove the soundness of their unsafe code, but it will not obviate the need to write unsafe code itself.

Our documentation should clearly describe the relationship of zerocopy to Project Safe Transmute, noting:

1. the different abstraction levels of zerocopy and Project Safe Transmute
2. how the progression of Project Safe Transmute will affect zerocopy (see Investigate using compiler-based safe transmute analysis behind a feature/cfg flag #481)

[briansmith]

I don't want to mess up your issue tracker by talking about my own needs too much, so I left a comment in the ring-specific issue: #450 (comment). Basically, the suggestion is more clearly delineate/separate the safe transmute aspect of zerocopy from the packet parsing, endian processing, and convenience stuff. I hope I explained why such separation is useful for ring and probably other crypto libraries, though I've no idea how practical it is.