[rabbit] Add option to specificy additional headers to RabbitMessageChannelBinder

[dnijssen]

In our use-case we have a @RabbitListener listening on the .dlq messages produced by the Spring Cloud Stream Rabbit binder. The default RabbitMessageChannelBinder already adds several headers related to the exception. Such as x-exception-message and x-exception-stacktrace. However we would like to have the option to add additional headers, e.g. for us to specificy the x-exception-cause as well.

Actual the constants used to define the header names in the RabbitMessageChannelBinder originate from Spring AMQP's RepublishMessageRecoverer where it is possible to add additional headers. It would be great to have similar option in Spring Cloud Streams RabbitMessageChannelBinder

[artembilan]

The RepublishMessageRecoverer in Spring AMQP has a logic like:

	/**
	 * Subclasses can override this method to add more headers to the republished message.
	 * @param message The failed message.
	 * @param cause The cause.
	 * @return A {@link Map} of additional headers to add.
	 */
	protected @Nullable Map<? extends String, ?> additionalHeaders(Message message, Throwable cause) {
		return null;
	}

So, to support custom headers this class has to be extended.

Doesn't look like RabbitMessageChannelBinder uses instances of this class, just those constants:

				private MessageProperties adjustMessagePropertiesHeader(Throwable cause, String stackTraceAsString, Message amqpMessage) {
					MessageProperties messageProperties = amqpMessage
							.getMessageProperties();
					Map<String, Object> headers = messageProperties.getHeaders();
					headers.put(RepublishMessageRecoverer.X_EXCEPTION_STACKTRACE,
							stackTraceAsString);
					headers.put(RepublishMessageRecoverer.X_EXCEPTION_MESSAGE,
							cause.getCause() != null ? cause.getCause().getMessage()
									: cause.getMessage());
					headers.put(RepublishMessageRecoverer.X_ORIGINAL_EXCHANGE,
							messageProperties.getReceivedExchange());
					headers.put(RepublishMessageRecoverer.X_ORIGINAL_ROUTING_KEY,
							messageProperties.getReceivedRoutingKey());
					if (properties.getExtension().getRepublishDeliveyMode() != null) {
						messageProperties.setDeliveryMode(
								properties.getExtension().getRepublishDeliveyMode());
					}
					messageProperties.incrementRetryCount();
					return messageProperties;
				}

I don't have a strong opinion, but looks like some functional callback could be configured on this RabbitMessageChannelBinder to provide the way for those custom headers against the message and cause.