Revise creation of ErrorMessage in the framework copying failed message headers

[artembilan]

There is a patterns when we would like to produce an ErrorMessage and do something called compensation reply in the error handling sub-flow.
To fulfill request-reply pattern requirements, we have to have a replyChannel header to be able to reply correctly after error handling.
Right now this leads into some extra transformation step to carry out headers from the failed message of the handled ErrorMessage into our reply Message:

        @Transformer(inputChannel = "errorHandlerChannel")
        Message<String> errorHandler(Message<MessagingException> errorMessage) {
            return MessageBuilder.withPayload("Request failed for: " + errorMessage.getPayload().getFailedMessage().getPayload())
                    .copyHeaders(errorMessage.getPayload().getFailedMessage().getHeaders())
                    .build();
        }

See an example on StackOverflow: https://stackoverflow.com/questions/74658669/error-handling-issue-with-http-responseentity-using-expressionevaluatingrequesth

If we would copy failed (request) message headers into an ErrorMessage, we would not need extra message building code in that error handler to produce compensation reply correctly:

        @Transformer(inputChannel = "errorHandlerChannel")
        String errorHandler(MessagingException payload) {
            return "Request failed for: " + payload.getFailedMessage().getPayload();
        }

[artembilan]

The use-case which we need to take into account: https://stackoverflow.com/questions/75249125/spring-integration-default-response-for-jms-inboundgateway.
With handleSendAndReceiveError() we cannot rely on the failedMessage headers since in direct processing its replyChannel header is marked as tempReplyChannel.setSendFailed(true);.

[artembilan]

Well, apparently the original request for the ExpressionEvaluatingRequestHandlerAdvice is fixed via #8893 .

We cannot change the logic in the handleSendAndReceiveError() according to the explanation above.
Therefore closing this as Won't Fix.

We may come to other use-cases when their arise.