Disable simplecov before rspec retries

What does this MR do?

Closes #365379 (closed).

Disables SimpleCov during rspec retries, so the coverage report doesn't get overriden by retried specs.

Took me a while to verify this in the pipelines, but I was able to confirm the fix with the following builds by forcing the pipeline_replicator spec to fail:

• Before: https://gitlab.com/gitlab-org/gitlab/-/pipelines/568490147
• After: https://gitlab.com/gitlab-org/gitlab/-/pipelines/569684777

Before the fix:

• The coverage artifactshows the following incorrect coverage result for pipeline_replicator.rb

"/builds/gitlab-org/gitlab/ee/app/replicators/geo/pipeline_replicator.rb": {
        "lines": [
          null,
          null,
          1,
          1,
          1,
          null,
          1,
          0,
          null,
          null,
          1,
          0,
          null,
          0,
          null,
          null,
          1,
          0,
          null,
          null,
          null
        ]
      },

• Undercoverage result: FAIL

undercover: 👮‍♂️ some methods have no test coverage! Please add specs for methods listed below
🚨 1) node `model` type: class method,
      loc: ee/app/replicators/geo/pipeline_replicator.rb:7:9, coverage: 0.0%
7:     def self.model hits: n/a
8:       ::Ci::Pipeline hits: 0
9:     end hits: n/a

After the fix:

• The coverage artifact shows the correct coverage details:

"/builds/gitlab-org/gitlab/ee/app/replicators/geo/pipeline_replicator.rb": {
        "lines": [
          null,
          null,
          1,
          1,
          1,
          null,
          1,
          4,
          null,
          null,
          1,
          3,
          null,
          1,
          null,
          null,
          1,
          1,
          null,
          null,
          null
        ]
      }

• Undercoverage result: PASS

undercover: ✅ No coverage is missing in latest changes

Related issues

#365379 (closed)

Checklist

Pre-merge

Consider the effect of the changes in this merge request on the following:

• Different pipeline types
• Non-canonical projects:
  • gitlab-foss
  • security
  • dev
  • personal forks
• Pipeline performance

If new jobs are added:

• Change-related rules (e.g. frontend/backend/database file changes): _____
• Frequency they are running (MRs, main branch, nightly, bi-hourly): _____
• Add a duration chart to https://app.periscopedata.com/app/gitlab/652085/Engineering-Productivity---Pipeline-Build-Durations if there are new jobs added to merge request pipelines

This will help keep track of expected cost increases to the GitLab project average pipeline cost per merge request RPI

Post-merge

• Consider communicating these changes to the broader team following the communication guideline for pipeline changes