Fix unintentional downgrades when gemspec DSL is used

[deivid-rodriguez]

What was the end-user or developer problem that led to this PR?

Bundler sets >= <locked_version> additional resolution requirements for all direct dependencies, in order to avoid downgrades.

Those are passed on to the resolver through this array here:

rubygems/bundler/lib/bundler/definition.rb

Lines 885 to 891 in 084f7d1

	def additional_base_requirements_for_resolve(last_resolve)
	return [] unless @locked_gems && unlocking? && !sources.expired_sources?(@locked_gems.sources)
	converge_specs(@originally_locked_specs - last_resolve).map do |locked_spec|
	Dependency.new(locked_spec.name, ">= #{locked_spec.version}")
	end.uniq
	end

In this case thought, an empty array is being passed (so no additional lower bound requirements due to sources.expired_sources?(@locked_gems.sources) being true.

That accounts for the case when the user changes Gemfile sources, expiring those in the lock file. In that case, it's possible that a gem in the new source needs to be downgraded, so lower bound requirements are not passed.

Here, however, nobody is changing any sources, and that method is still returning true. That's the bug. Closer inspection reveals that the Source::Path source included in Gemfile.lock is being considered different to the Source::Gemspec source included in the Gemfile. They are actually the same thing though.

What is your fix for the problem, implemented in this PR?

This commit fixes the issue by properly normalizing Gemspec and Path sources so that they can be properly compared.

Fixes #6129.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags