Don't link libsnappy explicitly

[arkpar]

It is already linked by rocksdb-sys which is a dependency.
Should help with #4836

[gavofyork]

if we switch from rocksdb to lmdb, wouldn't this break our linking? (it seems like we would be relying on an undocumented side-effect)

[debris]

if we switch from rocksdb to lmdb, wouldn't this break our linking?

Yes

what do you think about small hack with features?

Cargo.toml

[features]
default = ["rocksb"]

snappy.rs

// snappy is already linked by rocksdb
#[cfg(non(features='rocksb'))]
mod non_rocksb {
    #[link(name = "snappy", kind = "static")]
    extern {}
}

[arkpar]

#[link(name = "snappy", kind = "static")] is wrong anyway, because it assumes that there's a library already available in the system. If at some point we'd remove rocksdb it would break in even worse way. It would use the system library that some systems have and some don't and it won't work with cross-compiling scenarios.
Proper way is to have libsnappy-sys and libsnappy rust bindings is a separate crate. if we switch from rocksdb to lmdb this will indeed break things and we'll have add that crate eventually.