Consider merging MavenArtifact and MavenMetadata into a single content model

Problem Statement

pulp_maven maintains two separate content models — MavenArtifact and MavenMetadata — which adds significant complexity:

• Routing logic to decide which model to use (is_metadata(), get_remote_artifact_content_type())
• XML parsing required to extract GAV for metadata files (#367, #371)
• Separate serializers, viewsets, and API endpoints for each
• Checksum sidecar files need parent lookups to inherit GAV (#371)
• The deploy API has branching logic for each type

Proposal

Merge into a single content model with:

• version nullable
• Single API endpoint
• No routing logic needed — all Maven content is the same type

Design Decisions

Content unit creation

A new content unit is created each time content is uploaded, even if the GAV+filename matches an existing unit. This means:

• retrieve() returns None (always creates new)
• Multiple content units with the same GAV+filename can coexist in the system
• repo_key_fields handles deduplication at the repository level — when a new content unit with the same GAV+filename is added to a repo, the old one is automatically removed
• Old content units become orphans when removed from all repositories, cleaned up by orphan cleanup

Unique constraint

Use (group_id, artifact_id, version, filename, sha256, _pulp_domain) — includes sha256 so that each unique file produces a unique content unit. This allows multiple versions of the same logical file to coexist across different repositories or as orphans awaiting cleanup.

Benefits

• Eliminates XML parsing for GAV extraction
• Eliminates checksum sidecar parent lookup logic
• Simplifies deploy API (no is_metadata() branching)
• Simplifies pull-through cache (single get_remote_artifact_content_type return)
• Fewer serializers, viewsets, and tests to maintain
• Clean rebuild workflow: upload new content, add to repo, old content auto-replaced by repo_key_fields

Considerations

• Requires database migration
• Breaking API change (two endpoints → one)
• Should be coordinated with the publication model work (PULP-1946)

Related

• #367, #368, #371 — complexity caused by the two-model design
• #374 — pull-through cache metadata handling
• #375 — repo_key_fields (applies to both models identically)
• PULP-1946 — publication model (good time to refactor)

Start by reading the MavenArtifact and MavenMetadata models, then trace is_metadata(), get_remote_artifact_content_type(), the serializers, viewsets, deploy API, and repo_key_fields behavior. Review the related work in #367, #368, #371, #374, #375, and PULP-1946 before deciding the migration and API scope. Done means one content model and endpoint replace the two-model routing while repository-level replacement and orphan cleanup still work.