Vendor net-http, net-protocol, resolv, and timeout to reduce conflicts between Gemfile gems and internal dependencies

[deivid-rodriguez]

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

Problems with our internal usage of default gems getting in the middle of our users.

Running the following script on Ruby 3.2 without any timeout version other than the default install reproduces the issue:

require 'bundler/inline'

gemfile(true) do
  source 'https://rubygems.org'
  gem 'timeout'
end

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

Vendor net-http, net-protocol, resolv, and timeout.

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

[deivid-rodriguez]

I'd like to add a spec for the user problem this is fixing, but other than that it's ready. I know @hsbt does not like this, so I'd like to ask more opinions to avoid just imposing my perspective.

I already said why I think we should do this in #6773 (comment).

I know it's annoying to vendor 10K lines of code, but it is what it is right now. Also I think it's good that Bundler & RubyGems will always use the same code for these gems, rather than having varying behavior depending on which version of net/http or whatever is installed in the user's system. I did get confused by this in the past.

[hsbt]

Thank you for considering that. I understood this problem and your concern.

I worried that is not only for code management. The official ruby package size is increased in recent years.

ruby-2.7.8.tar.gz 16950365
ruby-3.0.6.tar.gz 21315725
ruby-3.1.4.tar.gz 20917933
ruby-3.2.2.tar.gz 20467023
ruby-3.3.0-preview3.tar.gz 21550473

It's not only caused vendoring code. Especially, Ruby 3.3 has Prism parser and related code. Ruby core team are also negative to manage duplicated code like net-http, timeout on ruby repo.

I have no idea to resolve both problem that are specified any versions and not vendoring them.

[deivid-rodriguez]

I don't think increased ruby package size is a strong reason to not do this, to be honest. This PR "just" increases about 70K the rubygems package size.

[martinemde]

I thought about this a bunch and talked with @deivid-rodriguez. I don't think this is the very best long term solution. I'd imagine rg&b playing nicely with any version of a stdlib that is loaded. However, this is not where this project is at right now, so I think we should stick with the plan in the RFC until we have a better plan. This is consistent with that plan.

[deivid-rodriguez]

Since I got someone else to back me up, and @hsbt said privately he's ok with vendoring if we decide so, I set this PR to be merged after CI.