Cargo requires a registry update when adding dep that already exists in dag

[brson]

Starting with two projects, with foo depending on bar:

[package]
name = "foo"
version = "0.1.0"
authors = ["Brian Anderson <[email protected]>"]

[dependencies]
bar = { path = "bar" }

[package]
name = "bar"
version = "0.1.0"
authors = ["Brian Anderson <[email protected]>"]

[dependencies]
libc = "0.2.0"

If I then add libc = "0.2.0" to foo/Cargo.toml Cargo will sync the registry. It already has all the info it needs to solve the graph though. Moving dependencies around in the graph is common in large projects, so Cargo should recognize this case and not hit the network.

[brson]

cc @wycats After some experimenting with a few dag-modifying ops this is the only one I found that still requires a registry sync. Better than I thought.

[aidanhs]

+1 for me (per my comment at #2111 (comment))

Also want to respond to #2811 (comment)

The various flags proposed in this PR assert that you won't need to hit the network. In general, if you don't need to hit the network but end up blocked on proceeding due to the lack of network that is a bug in Cargo.

"doesn't need to hit the network" is a little fuzzy - currently cargo says "I need to hit the network to write out a correct new Cargo.lock". I believe this is sane default behaviour (otherwise builds depend on what's already been cached). However

1. sometimes people want to say "just assume the index you have is fine" because they have appropriate packages cached
2. more subtly, sometimes people want to say "try really hard to build this package using the cache you have available", e.g. if I have greatlib 1.0.0 cached, but an index update has downloaded the info for greatlib 1.0.1, I actually don't want cargo to try and fetch greatlib 1.0.1

2 seems very hard and potentially extremely slow if no limits are put in place for cargo searching for things, but I can't currently think of a situation where just 1 would be better than 1+2.

As a result, I'd like to propose a new flag called --dev-working-offline (or whatever) and the intent is that this flag would be an umbrella for anything that makes cargo to try really hard to work offline - initially just 1, then much later 2 and potential others.