Remote cargo client/server API/Plugin Architecture for custom package sources

A frequent requirement for larger organizations is that some common code may not be "open source" within the organization, with access being limited to a small team. However, Rust crates need to be recompiled to match the exact version of Rust. This ticket is an attempt to resolve that contradiction by allowing an organization to deploy a cargo server that provides all of the build targets/artifacts that would normally be build on the users system.

This could have additional benefits, cost and environmental impact, for organizations by allowing sharing of compute resources and build artifacts(if many users are building the same crate, avoid rebuilding by hashing the inputs and returning the already built artifacts). Additionally, this would allow for distributed builds.

[dependencies]
package_a = { remote = "192.168.1.123:54321", version = "1.1" }
package_b.subpackage = { remote = "192.168.1.124:54321", version = "0.2" }

# or build with a federation of remotes, which would query each server and use the one with the shortest build queue
package_a = { remote = [ "192.168.1.123:54321", "192.168.1.124:54321" ], version = "1.1" }
package_b.subpackage = { remote = [ "192.168.1.123:54321", "192.168.1.124:54321" ], version = "0.2" }

Fully implementing this in cargo could be a fools errand, but a remote source plugin/API would allow organizations to build their own remote client/server layers(where servers could download/manage the correct version of Rust, etc.)

[dependencies]
package_a = { remote = "192.168.1.123:54321", ssh_args=["-i", "~/.ssh/id_rsa"], remote_plugin = "cargo-ssh", version = "1.1" } # This would SSH into a remote server to build the package and return the artifacts
package_c = {  remote_plugin = "cargo-ssh", version = "1.1" } # default remote hosts are specified in config
package_b.subpackage = {  remote_plugin = "cargo-ship", version = "0.2" } # I think "cargo-ship" would be a clever name for the first remote cargo repository ;)

[dev-dependencies]
cargo-ssh = "0.1.0" # host keys configuration would be specified in config.toml
cargo-ship = "0.1.2" # hosts and authentication configuration would be specified in config.toml

The issue names no repository files or tests. Start by reviewing the Cargo package-source and dependency-resolution areas relevant to remote artifacts and plugins, then define a concrete scope for the proposed API. Done would require an accepted design with clear implementation and validation criteria.