Refactor referrer detection to be more flexible / replaceable #20067

Our current referrer detection is hard coded into the referrer plugin, without any possibility to hook into it.
This makes it hard for plugins to manipulate that part in a useful way as it's only possible to overwrite the detected values afterwards.

I would suggest to refactor the whole detection part into a more flexible design.

First proposal:

• Separate classes for each referrer type detection (e.g. SearchEngine, Social, Campaign, ...), all implementing a certain abstract/interface
• Some sort of registry class, where plugins can register new referrer types, replace already registered classes or change the order of detections
• The referrer detection will then fetch all available detections from the registry and walk through all of them, to detect the referrer details.

Once this was implemented, we need to adjust the MarketingCampaignsReporting plugin, so it's detection uses the new possibilities.

refs L3-362

@sgiehl is this similar / related to https://github.com/matomo-org/matomo/issues/18511 ?

Yes. That should make it possible to fix that one

FYI this issue shows up in the visitor profile, visits log and in the reports. For example if you have segments that use a specific campaign property as the condition, the visit would be included but because of the bug the segment reports could show it as ‘Direct Entry’ or as a different campaign completely.

 This also means that the standard campaign reports could also be wrong, i.e. showing a higher number of direct entry even when a visitor actually entered through a campaign or showing as a potentially different campaign.