Eliminate multiple versions of the same crate within our transitive dependencies

[bstrie]

Low-priority successor to #387 which should wait for #140 to be addressed first. Currently our full crate graph contains several different copies of the same dependency, due to some of our dependencies requiring incompatible versions. We can see these by running git grep "name =" Cargo.lock | uniq -c | grep -v "1 Cargo.lock" | sort -r, which as of today gives me:

   3 Cargo.lock:name = "rand_core"
   3 Cargo.lock:name = "rand"
   2 Cargo.lock:name = "winapi"
   2 Cargo.lock:name = "url"
   2 Cargo.lock:name = "unicode-xid"
   2 Cargo.lock:name = "unicase"
   2 Cargo.lock:name = "syn"
   2 Cargo.lock:name = "serde_urlencoded"
   2 Cargo.lock:name = "rand_os"
   2 Cargo.lock:name = "rand_hc"
   2 Cargo.lock:name = "rand_chacha"
   2 Cargo.lock:name = "quote"
   2 Cargo.lock:name = "proc-macro2"
   2 Cargo.lock:name = "percent-encoding"
   2 Cargo.lock:name = "mime_guess"
   2 Cargo.lock:name = "mime"
   2 Cargo.lock:name = "log"
   2 Cargo.lock:name = "idna"

This could be partially addressed by pruning unnecessary dependencies from our crate graph (which is why this ought to wait for #140 first), but ultimately this might require manually patching dependencies who are slow to update.

[emschwartz]

Can this be closed now?

[bstrie]

I believe this predates the great default-features = false refactor; today it looks like this instead:

   3 Cargo.lock:name = "rand_core"
   3 Cargo.lock:name = "rand"
   2 Cargo.lock:name = "winapi"
   2 Cargo.lock:name = "uuid"
   2 Cargo.lock:name = "url"
   2 Cargo.lock:name = "serde_urlencoded"
   2 Cargo.lock:name = "rand_os"
   2 Cargo.lock:name = "rand_hc"
   2 Cargo.lock:name = "rand_chacha"
   2 Cargo.lock:name = "percent-encoding"
   2 Cargo.lock:name = "log"
   2 Cargo.lock:name = "idna"

So we did manage to get rid of 7 duplicated dependencies. I'm not entirely satisfied, but this is such a low priority for now (especially since now we have a good understanding of where in the pipeline our compilation time problems are, and are unrelated to duplicated dependencies) that I don't think it's useful to keep this open as a separate issue from #140 (which I still would like to do one day, after 1.0).