Draft: Prepend path prefixes for GitLab Edition into RuboCop config dynamically

What does this MR do and why?

Proof of concepts for #356503 (comment 1160587252).

Example

Given the following configuration in .rubocop.yml

Before this patch

Some/Cop:
  Exclude:
    - 'spec/**/*.rb'
    - 'ee/spec/**/*.rb'

It excludes files from spec/ (FOSS) and ee/spec (EE) but not other Editions like JiHu.

RuboCop uses the config as-is. Nothing is added dynamically after the configuration is loaded.

After this patch

We can remove the glob for EE.

Some/Cop:
  Exclude:
    - 'spec/**/*.rb'

When loading the configuration we prepend path prefixes to all Includes/Excludes entries.

The configuration is different per GitLab Edition as shown below. This shows how RuboCop sees now the modified configuration for:

FOSS

No changes from defined configuration in .rubocop.yml because we don't need to prepend anything.

Some/Cop:
  Exclude:
    - 'spec/**/*.rb'

EE

Both spec/**/*.rb and ee/spec/**/*.rb are excluded which matches the original example ✅

Some/Cop:
  Exclude:
    - '{,ee/}spec/**/*.rb'

JiHu

Here's the crux of this patch. When run in JiHu Edition (jh/ must exist) we also inspect jh/spec/**/*.rb additionally 🎉

Some/Cop:
  Exclude:
    - '{,ee/,jh/}spec/**/*.rb'

Draft?

• Proper MR description
• Add specs
• Add development guidelines describing
  • Why this patch is done. Spoiler: Conciseness, consistency and file matching performance
  • How to debug. Spoiler: `rubocop --show-cops [, ...]
• Test different editions (FOSS, EE; JiHu)
  • Check runtime of job rubocop

How to set up and validate locally

# FOSS mode
FOSS_ONLY=1 bundle exec rubocop --show-cops > foss.txt

# EE mode
bundle exec rubocop --show-cops > ee.txt

# JiHu mode
mkdir jh/ 
bundle exec rubocop --show-cops > jh.txt

diff -u foss.txt ee.txt
diff -u ee.txt jh.txt

All configs are different and contain path prefix targeting the current mode.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.