Add default content guard auto-assignment for distributions within a domain

[dkliban]

Summary

Adds a default_content_guard field to the Domain model. When a distribution is created within a domain that has a default_content_guard set and the distribution does not specify its own content guard, the domain's default is automatically assigned. To apply multiple guards by default, set a composite content guard as the domain's default_content_guard.

Changes

• Domain.default_content_guard foreign key (nullable, on_delete=SET_NULL) + migration
• Distribution BEFORE_CREATE hook auto-assigns the domain default when no guard is specified (an explicit content guard always wins)
• DomainSerializer exposes the field (plus a _prn convenience field) and validates that the guard belongs to the same domain
• DomainViewSet select_related to avoid N+1 on list

Tests

• Unit: serializer validation (cross-domain rejected, rejected on create, same-domain accepted)
• Functional (pulpcore): domain default_content_guard CRUD
• Functional (pulp_file): end-to-end auto-assignment and explicit-guard-wins

Closes: #7988

🤖 Generated with Claude Code

[dralley]

Setting aside the precise implementation, is the goal actually to assign a default value for the content guard, or is it to protect content by default with a certain guard?

Those are slightly different things - in the latter case, maybe you would leave the default value on the distribution null, but null would be remapped to a globally default content guard implicitly.

The semantics are different, in the former case changing the default content guard wouldn't change any distributions, they would need to be updated manually, whereas in the latter case all distributions left in a default state would be remapped to a different content guard.

[dkliban]

@dralley you bring up a good question. explicitly setting the content guard on a distribution should make it easier to debug any issues when a user is having issues with accessing content.

[dkliban]

Fixed — switched to single backticks in the changelog entry.

[dralley]

What is related_name="+"?

[dkliban]

related_name="+" is Django's convention for suppressing the reverse accessor entirely. Without it, Django would create content_guard.domain_set (or similar) pointing back to domains — a second traversal path that would be unused and confusing since ContentGuard already has its own pulp_domain FK for that. The + keeps the FK without polluting the ContentGuard namespace with an accessor nobody would call.

[dralley]

@dkliban Formatting

[dkliban]

Fixed the CI failure in . The domain deletion task was failing because ContentGuard.pulp_domain has on_delete=PROTECT — a domain with content guards in it cannot be deleted directly. The test creates a guard inside the domain, so the finally block now explicitly deletes the guard before deleting the domain. gen_object_with_cleanup still provides a backup safety net (it'll get a 404 on its cleanup attempt and handle it gracefully).