Speed up dealing with non-reachable git repos

[deivid-rodriguez]

While working on a spec failure, I observed the failing spec was also soooooo slow:

Top 1 slowest examples (48.37 seconds, 100.0% of total time):
  Dependabot::EndToEndJob bundler git dependencies updates dependencies correctly
    48.37 seconds ./spec/dependabot/integration_spec.rb:296

Further investigation revealed that this spec was trying to do the following up to 76 times, on a non-existing github repository:

• Try fetch https://github.com/dependabot/dummy-git-dependency.git/info/refs?service=git-upload-pack.
• Since the previous fetch failed, try run git ls-remote https://github.com/dependabot/dummy-git-dependency.git locally.

This is done every time the update checker needs to fetch remote git tags, and if this fails, the checker considers that there are no remote tags, but will keep on retrying the same thing and failing once and again.

This commit changes the commit fetcher to memoize the tags the first time they are fetched. With this change, the spec is now much faster:

Top 1 slowest examples (4.26 seconds, 100.0% of total time):
  Dependabot::EndToEndJob bundler git dependencies updates dependencies correctly
    4.26 seconds ./spec/dependabot/integration_spec.rb:296

I expect this to also improve things in production, of course.

[landongrindheim]

I think this makes a lot of sense! I'm assuming we're okay with not picking up the (likely) small number of cases where a tag is found on retry.

[deivid-rodriguez]

My understanding is that GitDependenciesNotReachable would be a non-retryable error, but we could make the logic more fine grained to make sure: let tag fetcher raise the original exception if its a RepoNotFound error, and memoize only in that case.

However, I'm not sure what the result will be if the update checker gets inconsistent results about the available remote tags 😬.