PowerDNS conflicts bundled with other errors are not recognised and retry forever

[aflor024]

What needs to happen

A PowerDNS coexistence conflict should be recognised as one no matter which part of the response body carries the reason.

Why this matters

pdnsErrorBody has a single field, Error string, and both IsConflict and FriendlyMessage read only that. PowerDNS has a second response shape for a write that hits several problems at once, captured live in #51:

{"error": "Multiple errors found in RRset", "errors": ["RRset x. IN NS: duplicate record with content \"...\""]}

There the top-level error is only a summary and the real reasons sit in errors[], which nothing reads. A conflict arriving that way isn't classified, so two things go wrong: the reconcile returns an error and retries indefinitely — exactly the hot loop #75 set out to stop — and the DNSRecordSet status shows the generic "The DNS record was rejected as invalid" instead of the actionable message.

This is latent rather than urgent. The conflict actually seen in production (#56, and the one driving datum-cloud/network-services-operator#315) is the single-error shape, which is handled today.

Desired outcome

IsConflict and FriendlyMessage classify a conflict whether the phrase appears in error or anywhere in errors[], with a test covering the multi-error body.

Related

• fix: Stop respelled owner names deleting live PowerDNS RRsets #75 — added the conflict classification this extends
• prod pdns backend returns 422 on PATCH /zones; new DNSZones never Accepted #51 — where the multi-error shape was captured
• Mode 3: ALIAS written over pre-existing RRset → PowerDNS 422 conflict #56 — the single-error shape, which already works