WIP: [AMQ-9455] DestinationPolicy support for MessageStrategy

[mattrpav]

Documentation notes:

1. Note about scenario of vm:// transport and disabling copyMessageOnSend and mutability/thread race issue

• [ ] Design change -- return the message from the strategy. If the message has changed (ie object equality is false), recalculate memory usage and continue.
• [ ] Rename to MessageInterceptorStrategy

[cshannon]

It's not really clear to me when I first read this what MessageStrategy was supposed to be from the name so I'm wondering if we should rename it. if this is supposed to be essentially an interceptor framework to mutate a message the maybe we just call it something like MessageInterceptor. However, I know we used the term "Strategy" elsewhere

Also, the API may need some discussion. A lot of times with something like this you might want to return the message so you can chain it and actually return an entirely different object, but this could have its own problems with things like potential memory usage not being tracked correctly. This only supports mutating in place which can have problems as well.

Anyways, the main thing is just making sure the public API is well thought out, named well, decide if we want to allow mutating in place only or not, etc because once it's out there it's hard to change it as people will create implementations.

[mattrpav]

@cshannon agreed, great points. +1 on returning the object in the API.

1. Re naming-- there is already a MessageInterceptor.java that is broker-wide, so I went with 'Strategy' since it matches the other sub-items on PolicyEntry -- SlowConsumerStrategy, DeadLetterStrategy, etc. That being said, I'm not married to 'MessageStrategy' as a name in any way.

2. Great point re memory usage and mutating. I think a key decision is if we have some sort of core MessageStrategy handler that supports memoryUsage on behalf of the extensions, or if each extension is responsible for managing that. I think having a top-level handler would be better, so users could do simple things like 'require this header name' and not worry about queue internals like memoryUsage. The ChainMessageStrategy could do that handling so users could add 'simple' extensions as children to that or replace the strategy altogether and be responsible for memoryUsage and other queue internals themselves. Thoughts?

[cshannon]

So I double checked and yeah we pretty much just used "Strategy" for everything. So maybe we could make it more descriptive by adding an extra word to the name that describes it better like Message<something>Strategy instead of just MessageStrategy to convey what it is. Not sure... maybe MessageInterceptorStrategy, MessageEnricherStrategy, MessageMutatorStrategy, etc. I'm open for ideas