cargo publish -Z sparse-registry going to git api when crate contains a dependency

[AsafZalcman-jfrog]

Problem

In JFrog we have an automation that verifies the cargo sparse support using the nightly image.
since cargo 1.66.0-nightly (b332991 2022-10-13) our tests started to fail, and after investigation, we saw that when we tried to publish a crate that contains a dependency (that exists in the same registry, for example, artifactory), cargo executing index/info/refs request in order to resolve the dependency, instead of index/re/gi/registry_dep as we saw with cargo 1.66.0-nightly (b8f30cb 2022-10-10)

Steps

/usr/local/cargo/config:

[net]
�git-fetch-with-cli = true
[registry]
�default = "artifactory"
[source.artifactory]
  registry = "sparse+http://172.17.0.2:8081/artifactory/api/cargo/cargo-local-notb0ugzus/index/"
[source.crates-io]
�  replace-with = "artifactory"
[registries.artifactory]
 index = "sparse+http://172.17.0.2:8081/artifactory/api/cargo/cargo-local-notb0ugzus/index/"

Cargo.toml file:

[package]
�name = "cargo_test_package"
�version = "0.1.0"
�edition = "2021"
�publish = ["artifactory"]

�[dependencies]
  registry_dep = { version = "0.1.0", registry = "artifactory" }
� regular_dep = "0.1.0"

Possible Solution(s)

No response

Notes

No response

Version

No response

[Eh2406]

cc @arlosi.

Also were considering stabilizing sparse-registry in #11224 your real world feedback would be deeply appreciated.

[nadav-yo]

We at JFrog are now constantly test and monitor the nightly builds, so would love to provide additional feedback when needed. also, feel free to reach out to us as well whenever you want.