Faraday dependency causes unexpected Bundler behavior

Describe the Bug

https://github.com/puppetlabs/orchestrator_client-ruby/commit/6f8661ee27271d8c19a2699d59b8ef3e7044f9bb allowed orchestrator_client to use Faraday >= 2 as a dependency. When orchestrator_client is installed alongside another gem (such as puppet_forge or vmfloaty) that depends on Faraday ~> 1, Bundler installs an unexpected version of Faraday (1.9.0).

This scenario is fairly common in Puppet modules as the default PDK template includes Litmus (which uses Bolt, which uses orchestrator_client) and puppet_forge (by way of dependency_checker), the latest version of which depends on Faraday ~> 1.3.

Faraday 1.9.0 has dependencies that use native extensions, which can cause issues in tests if the runner does not have the necessary libraries installed.

Expected Behavior

Until orchestrator_client 0.7.1 Bundler would install Faraday 1.10.4, the latest 1.y release.

Steps to Reproduce

Create a gemfile with orchestrator_client and a gem that does not permit faraday >= 2:

source "https://rubygems.org"

gem 'orchestrator_client'
gem 'puppet_forge'

Run bundle install. Bundler will install faraday 1.9.0 instead of the expected 1.10.4.

Additional Context

I opened an issue upstream with Bundler about this: https://github.com/rubygems/rubygems/issues/8286

One of the maintainers explained why Bundler behaves this way better than I could and outlines a potential fix.

This issue has affected several Puppet modules:

• https://github.com/puppetlabs/puppetlabs-peadm/pull/528
• https://github.com/puppetlabs/puppetlabs-puppet_agent/pull/743
• https://github.com/puppetlabs/puppetlabs-augeas_core/pull/84

Start by reviewing commit 6f8661ee27271d8c19a2699d59b8ef3e7044f9bb and the gem dependency declarations, then reproduce the issue with the Gemfile containing orchestrator_client and puppet_forge. Done means Bundler selects Faraday 1.10.4 in this combination instead of 1.9.0, while preserving the supported dependency requirements.