Fixes #39372 - Extract displayMessage from validation errors

[chris1984]

When the Foreman/Katello API returns validation errors (422 status), it includes detailed error messages in the 'displayMessage' field. The exception handler was only checking 'message' and 'full_messages', causing detailed error information to be lost.

This commit updates handle_unprocessable_entity to check for 'displayMessage' first, matching the behavior of handle_foreman_error which already handles this field correctly.

Before:
Could not update the host

After:
Could not update the host:
Validation failed: Host example.com: Cannot add content view
environment to content facet. The host's content source does
not sync lifecycle environment 'Library'.

Before patch:

hammer -d host update --id 3 --content-view-environments Library/Zoo
Could not update the host.

After patch:

hammer host update --id 3 --content-view-environments Library/Zoo
Could not update the host:
Validation failed: Host host.example.com: Cannot add content view environment to content facet. The host's content source 'capsule.example.com' does not sync lifecycle environment 'Library'.

Testing Steps:

1. Create multiple Content Views (e.g., cv_1 & cv_2) and multiple Lifecycle Environments (e.g., 'Library' and 'Dev').

2. Publish new versions of all Content Views and promote them to the 'Dev' lifecycle environment.

3. Add only the 'Dev' lifecycle environment to the external Capsule, ensuring that the 'Library' lifecycle environment is not added. Then, synchronize the Capsule server.

4. Register the client to the Capsule server.

5. Try to update the hosts content view environments to one not synced on the capsule
   hammer -d host update --id 3 --content-view-environments Library/Zoo

6. Verify you see the real error and not the generic can't update host error

[jturel]

To recapture an in-person discussion:

A Katello PR has been opened to address the upstream given we are at a good time to do this kind of breaking API change which resolves tech debt, addresses the reported issue, and more closely aligns Katello's API with Foreman's.

Chris brought to my attention that the fix is to be backported, so the Katello change wouldn't be safe to use because of its breaking nature. We discussed an option like this:

In this repo

• Break the logic out regarding how to extract a printable message from an error response into a new method
• Call that method here print extract_error_message(response)

In hammer-cli-katello

• Since the error handler in h-cli-katello extends the one in this repo, override the extract_error_message method ex: super || response['displayMessage'] so that displayMessage will be shown in the terminal when an error occurs and all other behavior is preserved

[ofedoren]

Not a maintainer anymore, but if I would be, I'd accept this change. I mean, there is probably a better way to deal with different response messages for errors, but this is at least very straightforward and light, so 👍

[chris1984]

Tested on a 3.16(satellite 6.18) and 3.19(satellite 6.19) setup and still works, switched base branch to 3.19 stable. @stejskalleos can this get a merge please? It has multiple acks on it. For 5.0 we just change the API in Katello but we have to backport this fix for 6.18.z/6.19.z so hence why it's going into this branch