Consider merging MavenArtifact and MavenMetadata into a single content model

[dkliban]

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 (MavenMetadata content incorrectly parses GAV from maven-metadata.xml path #367, Checksum files for maven-metadata.xml fail XML parsing and lose GAV fields #371)
• Separate serializers, viewsets, and API endpoints for each
• Checksum sidecar files need parent lookups to inherit GAV (Checksum files for maven-metadata.xml fail XML parsing and lose GAV fields #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

• MavenMetadata content incorrectly parses GAV from maven-metadata.xml path #367, Parse GAV from maven-metadata.xml content instead of path #368, Checksum files for maven-metadata.xml fail XML parsing and lose GAV fields #371 — complexity caused by the two-model design
• Pull-through cache should not save maven-metadata.xml as content #374 — pull-through cache metadata handling
• Add repo_key_fields to MavenArtifact and MavenMetadata for automatic deduplication #375 — repo_key_fields (applies to both models identically)
• PULP-1946 — publication model (good time to refactor)