WiP: run task to update RGs to 3.2

[kares]

NOTE: requires more changes than initially assumed due LS NOT using the extracted stdlib files (vendor/jruby/lib/ruby/stdlib), its instead using the embeded stdlib jar as a source for loading any built-in library.
Despite a gem update --system applied (RGs updated to 3.2.5) at the location we'll load RGs that shipped with JRuby:

#<Gem::PathSupport:0x16e99306 @spec_cache_dir="/home/kares/.gem/specs", @home="/home/kares/workspace/work/elastic/logstash/vendor/bundle/jruby/2.5.0", @path=["/home/kares/workspace/work/elastic/logstash/vendor/jruby/lib/ruby/gems/shared", "/home/kares/workspace/work/elastic/logstash/vendor/bundle/jruby/2.5.0"]>

$LOAD_PATH: ["uri:classloader:/META-INF/jruby.home/lib/ruby/2.5/site_ruby", "uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib"]

$LOADED_FEATURES: ["java.rb", "jruby.rb", "jruby/util.rb", "enumerator.rb", "rational.rb", "complex.rb", "thread.rb", "uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/unicode_normalize.rb", "uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rbconfig.rb", "uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/compatibility.rb", "uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/defaults.rb", ...]

Gem::VERSION: 3.0.6

What does this PR do?

Why is it important/What is the impact to the user?

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files (and/or docker env variables)
• I have added tests that prove my fix is effective or that my feature works

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• loading LS might (rarely) fail due JRuby auto-load bug #12077

Use cases

Screenshots

Logs

[jsvd]

NOTE: requires more changes than initially assumed due LS NOT using the extracted stdlib files (vendor/jruby/lib/ruby/stdlib), its instead using the embeded stdlib jar as a source for loading any built-in library.

I don't think we should work around the fact that Logstash uses the jruby complete jar. At the moment I don't see a reason for Logstash core to rely on the big jar and also have the stdlib ruby files on disk.
Leveraging the core jruby jar instead + stdlib unpacked files should have multiple benefits:

• allow us to remove the complete jar, removing 25mb from the distribution
• speed up startup as we'd be loading stdlib from disk instead of a compressed jar file
• facilitate rubygems/bundler updates like the one being attempted in this PR

@kares can you create an issue to register this intent on moving away from jruby-complete jar?

I also suggest we close this PR and revisit the rubygems upgrade once we address the jar/stdlib packaging.