[Rest Api Compatibility] Voting config exclusion exception message

[pgomulka]

the exception message has changed in #55291. This is not covered by rest
api compatibility, so no need to return the old message for v7 requests.
This commit adds a transformation to allow for the 7.x test to pass with
a new exception message

relates #51816

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?
• If submitting code, have you built your formula locally prior to submission with gradle check?
• If submitting code, is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
• If submitting code, have you checked that your submission is for an OS and architecture that we support?
• If you are submitting this code for a class then read our policy for that.

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[joegallo]

So the previous version of this API accepted a node filter as a path argument.

That is, POST _cluster/voting_config_exclusions/<some_node_name>,<some_other_node_id> would have worked. So would have a large variety of other node filters, but the key thing about this example is that it actually could be translated to invocations of the current API.

What do you think about that? We could 'just' return an error (and I absolutely think that's defensible). OR, when we receive the parameter, we could inspect it to figure out if it's something we can translate into the current API, and then run it.

I'm on the fence about whether I think would be a good path to go down or not.

/cc @jakelandis @DaveCTurner

[jakelandis]

LGTM