Add ContentView resource with cross-domain scatter/gather utility

[YasenT]

Add ContentView resource with cross-domain scatter/gather utility

Problem

Content Sources (via tang) performs batch searches across repository versions spanning multiple domains by opening a raw pgx connection straight to Pulp's Postgres. This has three problems:

• It breaks under domain-DB-offloading — a single connection pool can't query tables that live on different physical RDS instances.
• It bypasses all Pulp RBAC, since queries never pass through the API layer.
• Callers must pass raw lists of repository version hrefs on every request, with no way to save, name, or share a search scope.
  Content Sources templates routinely mix repositories from a private org domain and shared/public domains, so cross-domain search is a first-class requirement, not an edge case.

What this adds

A new first-class Pulp resource, ContentView — a named, persistable object that composes distributions from multiple domains into a single searchable scope, replacing the raw-hrefs-per-request approach with a proper Pulp resource.

• Model (ContentView): domain-scoped like any other Pulp resource, but its distributions ManyToManyField can reference Distributions from any domain the user has read access to. Each distribution already carries version-tracking semantics (tracks latest repo, pinned version, or a publication), so the content view doesn't need to duplicate that.
• Full CRUD + RBAC: ContentViewViewSet extends NamedModelViewSet/RolesMixin/LabelsMixin with a standard DEFAULT_ACCESS_POLICY/LOCKED_ROLES, following existing pulpcore conventions. Any user in the same org can read/update/delete content views in domains they have access to.
• Cross-domain scatter/gather utility (pulpcore.app.util_content_view, exported via pulpcore.plugin.util): resolve_content_view_distributions, group_versions_by_domain, and scatter_gather let plugins resolve a content view's distributions to their current repository versions, group them by domain, and run per-domain queries that are merged in Python — the single-domain case collapses to one query, multi-domain does a bounded per-domain over-fetch.
• RBAC-aware resolution: user_can_view_domain respects domain-level core.view_domain permission checks during resolution, so a distribution the user has lost access to is silently excluded from search results rather than erroring; the content view detail endpoint's distributions_status field reports per-distribution status (ok, no_domain_access, deleted, etc.) so callers can see what's excluded and why.
• Nested search endpoints for plugins: router_lookup = "content_view" on ContentViewViewSet lets plugins (e.g. pulp_rpm) register read-only search viewsets nested under /content-views/{uuid}/search/... via rest_framework_nested.routers, reusing an existing content type's queryset without competing for that model's canonical viewset.
• Bugfix: get_viewset_for_model previously raised LookupError when a model had more than one registered viewset (its canonical viewset plus a plugin's nested, read-only search viewset reusing the same queryset) — a real bug hit during RPM sync once a plugin registers a nested search viewset. Fixed by disambiguating: if excluding nested viewsets (those with a parent_viewset) leaves exactly one candidate, that's the canonical viewset.

Out of scope (this PR)

• RPM-specific search endpoints (search/rpm/*) — implemented separately in pulp_rpm on top of this.
• Maven/NPM/Python content search.
• UI implementation.

Testing

• Unit tests for the model, cross-domain resolution logic, and scatter_gather (single- and multi-domain paths), including RBAC exclusion scenarios.
• Unit tests for the get_viewset_for_model disambiguation fix, covering both the resolvable and genuinely-ambiguous cases.
• Manually validated end-to-end (CRUD, cross-domain search, RBAC exclusion) against a live Postgres-backed instance alongside the companion pulp_rpm search endpoints.

[ggainey]

While I see that this particular user has this as a standard workflow - it violates the basic promise Pulp makes with domains, which is "no user gets access to a domain's content that they don't belong to". Even under RBAC, this extends the attack-surface for violating that promise quite widely.

I don't see this being something any Pulp installation other than Content Sources wanting. At an absolute minimum, I'd want a way for an installation to turn this off, and have that be the default.

This "feels like" it changes The Rules in ways that make it better-suited to being its own specific plugin, which an installation can choose to include, or not. But I don't think it belongs in the base project code.

[YasenT]

@ggainey Thank you for this, we agreed internally to keep it part of pulp-service only :)