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.

Integration Test

• Behavior was validated in an end-to-end WebSocket/STOMP scenario to ensure:

  • propagated headers flow through the Spring Messaging pipeline correctly,
  • no regressions occur in routing or delivery.

• Only unit tests are committed in this PR.

If preferred, I can also include the integration test in this PR.

[rstoyanchev]

Simplify the name to headerFilter, and no need for Javadoc on the field as well.

[catturtle123]

Agreed. I’ve renamed it to headerFilter and removed the field-level Javadoc to keep it consistent with existing style.

[rstoyanchev]

Instead of such a warning, which requires further investigation on its own, how about applying header propagation first, and then setting standard headers (like session id) second, so there is no possibility for overwriting.

[catturtle123]

That makes sense. I’ve removed the warning and updated the order so propagated headers are applied first, followed by standard headers, to avoid any possibility of overwriting.

[rstoyanchev]

We could allow multiple predicates to be provided, and combine those with Predicate#or, also changing the method name to add~ instead of set~.

[catturtle123]

Good suggestion. I’ve changed the API to addHeaderFilter and combined multiple predicates using Predicate#or.

[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.