[rubygems/rubygems] Allow disabling RubyGems require decorations

Currently Bundler needs to do cumbersome operations to revert custom
RubyGems require on a `bundler/setup` context. This causes issues when
third party gems also monkeypatch require, since Bundler will also undo
those decorations.

This commit allows it to use the simpler approach of properly telling
RubyGems that it needs to default to built-in require without any extra
magic.

https://github.com/rubygems/rubygems/commit/1df5009e14

Co-authored-by: Xavier Noria <fxn@hashref.com>

lib/rubygems.rb

@@ -181,6 +181,8 @@ module Gem
 
   @default_source_date_epoch = nil
 
+  @discover_gems_on_require = true
+
   ##
   # Try to activate a gem containing +path+. Returns true if
   # activation succeeded or wasn't needed because it was already
@@ -1162,8 +1164,16 @@ An Array (#{env.inspect}) was passed in from #{caller[3]}
     # RubyGems distributors (like operating system package managers) can
     # disable RubyGems update by setting this to error message printed to
     # end-users on gem update --system instead of actual update.
+
     attr_accessor :disable_system_update_message
 
+    ##
+    # Whether RubyGems should enhance builtin `require` to automatically
+    # check whether the path required is present in installed gems, and
+    # automatically activate them and add them to `$LOAD_PATH`.
+
+    attr_accessor :discover_gems_on_require
+
     ##
     # Hash of loaded Gem::Specification keyed by name
 

lib/rubygems/core_ext/kernel_require.rb

@@ -34,6 +34,9 @@ module Kernel
   # that file has already been loaded is preserved.
 
   def require(path) # :doc:
+    return gem_original_require(path) unless Gem.discover_gems_on_require
+
+    begin
       if RUBYGEMS_ACTIVATION_MONITOR.respond_to?(:mon_owned?)
         monitor_owned = RUBYGEMS_ACTIVATION_MONITOR.mon_owned?
       end
@@ -168,6 +171,7 @@ module Kernel
         end
       end
     end
+  end
 
   private :require