Description of problem:
When creating a content view filter for a package by name, I can see mixed results with the filter working as expected due to packages being modular and not being considered for RPM content view filters.

A better representation of what packages would be affected by a filter or certain type should be created.

Version-Release number of selected component (if applicable):
satellite-6.12.0-4.el8sat.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Create a content view with rhel-7-server-rpms repo only and add the filter to exclude RPM "389-ds-base". At the time of this writing, this filters out 55 packages which would be correct.

2. Create another content view with the "Red Hat Satellite Maintenance 6.12 for RHEL 8 x86_64 RPMs" with a filter to exclude package "rubygem-clamp" (all archs, all versions). This filters out nothing. Create another filter for this same content view and filter out "*" for the package name (all archs, all versions) and it filters out only "satellite-clone".
3.This is because all packages in the Satellite Maintenance 6.12 for RHEL 8 (at this time) are modular except for 1 (satellite-clone). This is not explained or understandable from the content view filter screen without having to navigate to other pages on the Satellite.

Actual results:
See "Steps to reproduce"

Expected results:

Inclusion/Exclusion should be applied to the repository no matter what the status of modularity or repository contains the stream its associated with.

WebUI should display the package's modularity status along with the stream they are associated with everywhere it's viewable to see packages:

• https://satelite.example.com/content_views/:content_view_id/versions/:version_id/rpmPackages
• https://satelite.example.com/packages
• https://satelite.example.com/products/:product_id/repositories/:repository_id
• etc

Additional info:
With the introduction of streams and modularity in RHEL 8 there has been a lot of confusion on why won't systems just update to the latest like yum always has. If DNF is going to treat RPMs differently at the OS level I believe Satellite should also reclass them as a "modular package" as opposed to including them under the umbrella term of "packages".