Honor concurrent_downloads from .gemrc in Gem::ConfigFile

[afurm]

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

concurrent_downloads values configured in .gemrc were ignored during Gem::ConfigFile initialization.
Even with concurrent_downloads: 2 in config, RubyGems kept using the default value (8).

This made .gemrc behavior inconsistent with other config options (like verbose, update_sources, etc.) that are properly applied.

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

I added a regression test to reproduce the issue:

• test_initialize_concurrent_downloads writes concurrent_downloads: 2 to a config file
• initializes Gem::ConfigFile
• asserts @cfg.concurrent_downloads == 2

Before the fix, that test failed (expected 2, got 8).

Root cause:

• concurrent_downloads was not included in the key normalization list that converts config keys to symbols
• and it was not assigned from @hash during initialization

Fix implemented:

• include concurrent_downloads in the transform-to-symbol allowlist
• assign @concurrent_downloads = @hash[:concurrent_downloads] when present

I chose this approach because it matches the existing pattern used for other RubyGems config options, keeps behavior consistent, and is minimal/risk-contained.

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

[colby-swandale]

Nice and easy! Thanks!

We'll probably need to update https://guides.rubygems.org/command-reference/ also, but that will need to be a separate PR.

[afurm]

Nice and easy! Thanks!

We'll probably need to update https://guides.rubygems.org/command-reference/ also, but that will need to be a separate PR.

Thank you! I have created a separate PR for guides. #9341