Make SendToMethodReturnValueHandler and SubscriptionMethodReturnValueHandler customizable, to allow for pass-through of message headers

[catturtle123]

This PR addresses issue #36168

Summary

• Added an opt-in mechanism to selectively propagate headers from an input Message to the outbound Message created by:

  • SendToMethodReturnValueHandler
  • SubscriptionMethodReturnValueHandler

• Header propagation is controlled via a configurable Predicate<String>.

• Default behavior remains unchanged: no headers are propagated unless explicitly configured.

Resolved Issue

• Allows applications to forward selected headers (e.g. correlation or receipt-related headers) while avoiding accidental propagation of internal or protocol-specific headers.
• Provides a simple and explicit customization point instead of always copying or discarding headers.

Scope

• This change applies only at the Spring Messaging layer.
• It affects how outbound MessageHeaders are populated by handler return value processing.
• It does not change STOMP native header serialization or WebSocket frame encoding.

Discussion Points

• Whether the public getter (getHeaderPropagationPredicate) should be retained, or removed to keep the API strictly write-only.
• The current scope of this PR is limited to propagating headers at the Spring Messaging level.
  A discussion point is whether this is sufficient for the intended use cases, or if extending the mechanism to STOMP native headers should be considered separately rather than as part of this change.

[catturtle123]

I've applied the requested changes (renaming to headerFilter, switching to add~ method with Predicate#or logic, and adjusting the execution order). I've squashed the changes into the main commit to keep the history clean as per the contribution guide. Sorry for making the delta review slightly harder.

[rstoyanchev]

No problem, I added an additional property on SimpAnnotationMethodMessageHandler to make it a little easier to configure.

[catturtle123]

Hi @rstoyanchev,

When I was working on this PR, I found that the propagated headers didn't actually reach the STOMP client. There are two issues:

Input side: STOMP custom headers (e.g. x-correlation-id) are stored inside the nativeHeaders sub-map, not as top-level MessageHeaders entries. So when headerFilter iterates over top-level keys, it never matches them.

Output side: Even if headers were copied to the top-level MessageHeaders, StompEncoder.writeHeaders() only serializes entries from the nativeHeaders sub-map, so they would never be written to the outbound STOMP frame.

That's why I had left it as a discussion point in the PR. Is the current scope what you intended, or should we extend propagation to STOMP native headers as well? If it makes sense to extend, I'd be happy to follow up with a PR.