feat: prevent draft creation for unchanged dataset metadata

[AnneGerlach]

What this PR does / why we need it:

🎫 Closes: #12376

This PR prevents Dataverse from creating or updating a draft version when metadata uploaded via PUT /api/datasets/{id}/versions/:draft is semantically identical to the existing dataset version.

Previously, repeated uploads of unchanged metadata created unnecessary draft versions. This was particularly problematic for automated synchronization workflows, which had to implement their own comparison logic before submitting updates.

The implementation reuses the existing DatasetVersionDifference logic to detect unchanged metadata and terms updates and skips draft creation or update when no effective changes are detected.

Changes

• Added a no-op check before draft creation and draft update in PUT /api/datasets/{id}/versions/:draft

• Reused the existing DatasetVersionDifference implementation to detect unchanged metadata and terms updates

• Skipped draft creation/update and returned the existing dataset version when no effective changes are detected

• Added integration tests covering both scenarios:

  • no draft exists
  • draft already exists

Suggestions on how to test this:

Run tests:

mvn test -Dtest=DatasetsTest,DatasetsIT

or tests manually:

Test no-op metadata update

1. Login as dataverseAdmin
2. Create and publish a dataset via the UI
3. Generate an API token and copy the dataset PID (export those: API_TOKEN and PID)

# Download latest version metadata
curl -H "X-Dataverse-key: $API_TOKEN" \
"http://localhost:8080/api/datasets/:persistentId?persistentId=$PID" \
| jq '.data.latestVersion' > latestVersion.json

# Re-upload unchanged metadata
curl -X PUT \
-H "X-Dataverse-key: $API_TOKEN" \
-H "Content-Type: application/json" \
--data @latestVersion.json \
"http://localhost:8080/api/datasets/:persistentId/versions/:draft?persistentId=$PID"

# Verify no draft was created
curl -H "X-Dataverse-key: $API_TOKEN" \
"http://localhost:8080/api/datasets/:persistentId/versions?persistentId=$PID" \
| jq

Test changed metadata

# Modify metadata in the file e.g.
nano latestVersion.json

# Upload changed metadata
curl -X PUT \
-H "X-Dataverse-key: $API_TOKEN" \
-H "Content-Type: application/json" \
--data @latestVersion.json \
"http://localhost:8080/api/datasets/:persistentId/versions/:draft?persistentId=$PID"

# Verify draft now exists
curl -H "X-Dataverse-key: $API_TOKEN" \
"http://localhost:8080/api/datasets/:persistentId/versions?persistentId=$PID" \
| jq

Special notes for your reviewer:

Thanks for reviewing 🌻 (and special thanks to @vera for reviewing beforehand 🌷 )

[stevenwinship]

Could you add a release note explaining the change

[stevenwinship]

@AnneGerlach When I tried this, changing the dataset contact email, it was treated as a no-op

Before:
"datasetContactEmail": {
"typeName": "datasetContactEmail",
"multiple": false,
"typeClass": "primitive",
"value": "spruce@mailinator.com"
}

Here is what I sent:
"datasetContactEmail": {
"typeName": "datasetContactEmail",
"multiple": false,
"typeClass": "primitive",
"value": "spruce1@mailinator.com"
}

Nothing changed when I get the draft:
"datasetContactEmail": {
"typeName": "datasetContactEmail",
"multiple": false,
"typeClass": "primitive",
"value": "spruce@mailinator.com"
}

Without this PR the email value gets updated
"value": "spruce1@mailinator.com"

[vera]

@AnneGerlach When I tried this, changing the dataset contact email, it was treated as a no-op

You're right. It seems this approach of simply re-using the DatasetVersionDifference implementation to detect no-op updates doesn't work.

Since DatasetVersionDifference uses display values and not the raw values for comparison, this fails to detect changes for a couple of specific field types:

• Compound child fields whose display format hides their actual value, such as #EMAIL (e.g. datasetContactEmail)
• Primitive fields with fieldType = "email", which are completely skipped during the comparison
• Primitive fields when only the letter case is changed, because primitive comparisons are case-insensitive
• Fields with display sanitization or escaping, where values become identical after sanitization/escaping

I've added examples for these to the testUpdateDatasetMetadataNoOp, so the IT tests are going to fail now.

To fix this, the change detection needs to be reworked to be based on raw values, not display values.