Supporting transitive path dependencies

[snowp]

While rules_rs supports resolving local path Cargo dependencies it seems to not handle path dependencies transitively being brought in from a path dependency.

 # Run ./bazelw mod tidy

  failed with:

  Found a path dependency on bd-artifact-upload 1.0.0 but could not determine its path from Cargo.toml.
  Please declare it in [patch] or as a path dependency.

Here bd-artifact-upload is not a direct dependency of the bazel workspace, and is instead being included transitively from the path dependency.

This is from testing bitdriftlabs/capture-sdk#1057 and using the ./tools/swap_local.sh utility script for targeting a sibling repo for local development which is the typical flow used for Cargo-based workflows in this repo. In our case this is loading https://github.com/bitdriftlabs/shared-core from ../shared-core, relative to the bazel repo. The bd-artifact-upload crate is brought in via https://github.com/bitdriftlabs/shared-core/blob/main/bd-logger/Cargo.toml#L16 and not referenced directly from capture-sdk.

My agent came up with a solution that calls calls cargo metadata without --no-deps to detect these kind of dependencies and generate the correct cargo metadata for each. Happy to push through a patch for this if this seems like the right approach

Tested this on 0.0.96 and HEAD

[dzbarsky]

Thanks for filing the issue. I think cargo metadata without --no-deps is unfortunately going to do too much work (such as fetching data from registries), but probably what we can do is look at the returned deps and invoke cargo metadata --no-deps on any path deps transitively? (I believe we actually hit this use case in internal usage due to very weird multiworkspace setups, but our setup is so not-recommended that I didn't want to pollute the OSS rules with our hacks :) )