Ban multiple versions of parity-util-mem

[ordian]

To avoid issues like #921, having multiple versions of parity-util-mem should be banned. This can be enforced in CI via https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.html or simply by running this command

! grep -qE "parity-util-mem [0-9].+[0-9] \(registry" Cargo.lock

To see where multiple versions of parity-util-mem come from, run (install cargo-tree first)

cargo tree -i -p parity-util-mem:0.6.0

and

cargo tree -i -p parity-util-mem:0.5.2

[rphmeier]

@ordian Will you prepare a PR? I don't want this to sit in the issue tracker indefinitely with a * dependency merged in #921

[burdges]

Rust should ban duplicate #[no_mangle] symbols, no? rust-lang/rust#28179 If so then adding one #[no_mangle] symbol should help detect this at compile time, although maybe this fails under some architectures, making the CI check good too.

[ordian]

@rphmeier I see @TriplEight self-assigned to this (probably for the CI check). Currently the problem is coming from substrate, memory-db needs to be bumped there in order to avoid multiple versions:
https://github.com/paritytech/substrate/blob/42ec6948af7ee2773d95e68bdf04d89abe2f716b/primitives/trie/Cargo.toml#L22

I know that ring uses thing workaround for detecting this at compile time:
https://github.com/briansmith/ring/blob/ddfa683266e8ce41c06feb9f46503dd4e1d47ab1/Cargo.toml#L15-L16

[bkchr]

What is the problem of having this util mem multiple times in the depdendcy graph?

[ordian]

@bkchr the problem is that if if one version doesn't enable jemalloc-global feature and another does, then you'll get UB, see #921 (comment)

[ordian]

Here is an example which segfaults on cargo run: https://github.com/ordian/multiple-parity-util-mem-issue.