Introduce API version namespaces and implement Gems::V2.info

[marcoroth]

This pull request introduces the V1 and V2 namespaces to handle both Rubygems.org APIs.

My main motivation was to use the /api/v2/rubygems/:gem/versions/:version.json endpoint with the gems gem.

The existing Gems::Client implementation was moved into the V1 namespace as Gems::V1::Client. I created a new V2 client as Gems::V2::Client which implements the above mentioned endpoint.

The Gems::Client still exists and inherits from Gems::V1::Client to be backwards compatible.

Also the class methods on Gems remain and delegate their methods to an Gems::Client/Gems::V1::Client instance.

Additionally all the V1 methods can also be accessed through the V1 module (this might help with future deprecation):

Gems.info 'rails'

# is the same as 
Gems::V1.info 'rails'

The V2 methods can only be accessed by explicitly calling them on the V2 module:

Gems::V2.info 'rails', '7.0.6'

I introduced a AbstractClient mixin to share the behavior between the class methods on Gems, Gems::V1 and Gems::V2.

Let me know if you have any feedback! Thank you!

[simi]

@marcoroth rebase should fix CI 🙏

[marcoroth]

Just rebased, the failing CI seems unrelated though

Edit: Ah, I guess it's the test coverage, will add a test

[simi]

Just rebased, the failing CI seems unrelated though

Edit: Ah, I guess it's the test coverage, will add a test

Feel free to ignore CodeClimate, but indeed specs are failing because of some method is missing coverage, but it fails hard because of probably some change in never simplecov. Repo is missing Gemfile.lock and has optimistic constraints in Gemfile. 🤷

[marcoroth]

Added some tests to bring the coverage back up

[marcoroth]

This one should be ready from my POV.

[manuelmeurer]

Would love to see a new version released with this change! 😄