[WIP] Lockfile checksum

[agrim123]

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

The main aim is to reduce Gemfile resolve time if checksum remains same.

What was your diagnosis of the problem?

Add a section CHECKSUMS to lockfile that will store the checksum and will be used to match for future.
I continued the work done by @segiddins.

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

The main approach was to store a checksum of current gemfile under CHECKSUMS sections in Gemfile.lock

In continuation of #5584.

[agrim123]

@segiddins I am not able to test static gemfile option, do not know how to call it from Gemfile like you said. Can you please help me here? And how shall I proceed with this PR?
And need some help in current failing tests!

[segiddins]

_static_gemfile! in the DSL

[simi]

Hello! I really like this feature.

I went thru code and I have 2 initial questions. Sorry if they were answered already, but I can't find any previous discussion related to those questions.

1. Why checksum can't be stored in file next to lock files?
2. I see md5 is used to digest lock. Can't something different (ex. SHA1) be used since md5 is blocked on FIPS enabled systems? There were some issues with md5 and FIPS before. I know there's md5_available? helper used to avoid problems. But do we really need to introduce new features with md5 and disable them for FIPS enabled systems?

[segiddins]

MD5 is quicker

[agrim123]

@segiddins
This test block is failing

context "with a current version" do
  let(:base_version) { Gem::Version.create(Bundler::VERSION) }

  it "returns an empty array" do
    expect(subject).to eq([])
  end
end

We have added sections in 2.0 version. And when we are testing with BUNDLER_SPEC_SUB_VERSION=1.98 this fails. How do I counter this?

[segiddins]

The lockfile parser hash of known sections would need an update

[agrim123]

I didn't quite understand how to proceed. Should we not change BUNDLER_SPEC_SUB_VERSION for test?