Fixes #35833 - Expose the origin of a config report

[ekohl]

Prior to this change there was no way to explicitly indicate the origin of a report and it used scanners to determine the origin. This is expensive because it relies on inspecting the data multiple times. On the other side it's pretty cheap to set the origin.

It is currently implemented as optional, falling back to the current behavior.

It also relies on the scanners to expose an origin. For compatibility it's guessed based on the class name. For example, AnsibleReportScanner is identified as Ansible. A deprecation warning for this is emitted.

Currently this is a draft to discuss the overall design. I'm sure I missed some details and it needs tests.

[theforeman-bot]

Issues: #35833

[ehelms]

I think the overall idea is good, and the fallback makes sense to me as that is fairly reliable. What percentage of the known scanners already set origin? If they don't, Is there pre-emptive work we need to do or file issues to help get this done to prevent breakages?

[ekohl]

@nofaralfasi mind having a look at this from an Ansible perspective?

[nofaralfasi]

I apologize for the delay in responding. As the PR is not yet ready, trying to test these changes didn't work for me. However, based on the information available, I see no reason why we shouldn't implement it. The necessary modifications to ansible_report_scanner.rb can be kept simple, and adding them should not be an issue.