Incorrect setuptargetrepos actor behavior

[l0g0sys]

Actual behavior
setuptargetrepos actor reports standard CentOS repositories as unknown and suggests that essential packages might not be upgraded.
Relevant output in /var/log/leapp/leapp-report.txt:
Risk Factor: low
Title: Some enabled RPM repositories are unknown to Leapp
Summary: The following repositories with Red Hat-signed packages are unknown to Leapp:

• elevate
• base
• updates
• extras
  And the following packages installed from those repositories may not be upgraded:
• nss-pem
• nss-tools
• less
• openssh-clients
• openssl-libs
• python2-leapp
• systemd
  ...
  (truncated)
  Remediation: [hint] You can file a request to add this repository to the scope of in-place upgrades by filing a support ticket
  Key: 8e89e20c645cea600b240156071d81c64daab7ad

To Reproduce
Steps to reproduce the behavior

1. Install VM from https://vault.centos.org/7.9.2009/isos/x86_64/CentOS-7-x86_64-Minimal-2207-02.iso
2. Change /etc/yum.repo.d/CentOS-Base.repo to use vault.centos.org for baseurl instead of mirrorlist
3. Update system: # yum update -y
4. Reboot system: # systemctl reboot
5. Install ELevate repository: # yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
6. Install Leapp packages for OL8 upgrade: # yum install -y leapp-upgrade leapp-data-oraclelinux
7. Run preupgrade checks: # leapp preupgrade
8. See output in /var/log/leapp/leapp-report.txt

Expected behavior
To get expected behaviour follow these steps:

1. Create empty /etc/leapp/files/vendors.d: # mv /etc/leapp/files/vendors.d /etc/leapp/files/vendors.d.off; mkdir -p /etc/leapp/files/vendors.d/rpm-gpg
2. Run preupgrade checks: # leapp preupgrade
3. See output in /var/log/leapp/leapp-report.txt

Relevant output in /var/log/leapp/leapp-report.txt:
Risk Factor: low
Title: Some enabled RPM repositories are unknown to Leapp
Summary: The following repositories with Red Hat-signed packages are unknown to Leapp:

• elevate
  And the following packages installed from those repositories may not be upgraded:
• python2-leapp
• leapp-deps
• leapp-upgrade-el7toel8-deps
• leapp-upgrade-el7toel8
• leapp-data-oraclelinux
• leapp
  Remediation: [hint] You can file a request to add this repository to the scope of in-place upgrades by filing a support ticket
  Key: 8e89e20c645cea600b240156071d81c64daab7ad

System information (please complete the following information):

• OS and version: CentOS Linux release 7.9.2009 (Core)
• Linux centos7.localdomain 3.10.0-1160.119.1.el7.x86_64 fixed version_id #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

# rpm -qa "leapp*"
leapp-deps-0.18.0-2.el7.noarch
leapp-upgrade-el7toel8-deps-0.21.0-4.el7.elevate.4.noarch
leapp-upgrade-el7toel8-0.21.0-4.el7.elevate.4.noarch
leapp-0.18.0-2.el7.noarch
leapp-data-oraclelinux-0.5-1.el7.20241127.noarch

Additional context
After adding some debug logging to /repos/system_upgrade/common/actors/setuptargetrepos/libraries/setuptargetrepos.py, it looks like code initializing setuptargetrepos_repomap.RepoMapDataHandler from RepositoriesMapping message(s) was not adjusted for multiple repository mappings when vendor repository mapping support was added (e.g. actor vendor_repositories_mapping).
The original code just picks first repository mapping, which in this case is parsed from /etc/leapp/files/vendors.d/docker-ce_map.json by vendor_repositories_mapping actor which is executed before repository_mapping actor parsing /etc/leapp/files/repomap.json during FactsCollection phase.
(I'm not well versed in Python neither Leapp tool, so my conclusion might be wrong)