Mutiny 1.7.0 with no prefetch concatmap

[ozangunalp]

• Bump mutiny to 1.7.0
• The hack needed for avoiding buffering is no longer needed
• Messages nacked when MessageConverter throws exception

[ozangunalp]

@kdubb for MessageConverter failure handling

[codecov-commenter]

Codecov Report

Merging #1837 (57c8abf) into main (b3bef5d) will decrease coverage by 61.35%. The diff coverage is 36.36%.

:exclamation: Current head 57c8abf differs from pull request most recent head 099862d. Consider uploading reports for the commit 099862d to get more accurate results

@@              Coverage Diff              @@
##               main    #1837       +/-   ##
=============================================
- Coverage     73.80%   12.45%   -61.36%     
+ Complexity     3153      438     -2715     
=============================================
  Files           276      276               
  Lines         11255    11253        -2     
  Branches       1438     1436        -2     
=============================================
- Hits           8307     1401     -6906     
- Misses         2264     9665     +7401     
+ Partials        684      187      -497     

Impacted Files	Coverage Δ
...active/messaging/providers/helpers/MultiUtils.java	0.00% <0.00%> (-87.50%)	:arrow_down:
...rye/reactive/messaging/kafka/impl/KafkaSource.java	50.44% <50.00%> (-34.65%)	:arrow_down:
...allrye/reactive/messaging/health/HealthReport.java	0.00% <0.00%> (-100.00%)	:arrow_down:
...ipse/microprofile/reactive/messaging/Metadata.java	0.00% <0.00%> (-100.00%)	:arrow_down:
...tive/messaging/ce/impl/BaseCloudEventMetadata.java	0.00% <0.00%> (-100.00%)	:arrow_down:
...messaging/ce/DefaultCloudEventMetadataBuilder.java	0.00% <0.00%> (-100.00%)	:arrow_down:
...ssaging/tck/SmallRyeReactiveMessagingExtender.java	0.00% <0.00%> (-100.00%)	:arrow_down:
...ing/ce/impl/DefaultIncomingCloudEventMetadata.java	0.00% <0.00%> (-100.00%)	:arrow_down:
...ing/ce/impl/DefaultOutgoingCloudEventMetadata.java	0.00% <0.00%> (-100.00%)	:arrow_down:
...smallrye/reactive/messaging/jms/JmsProperties.java	0.00% <0.00%> (-100.00%)	:arrow_down:
... and 217 more

[kdubb]

@ozangunalp This converter function still caches the last used converter. This is wrong, read my original PR for details.

[ozangunalp]

@kdubb I understand that the documentation doesn't say that the canConvert function is called once on lookup. But I don't think that the current implementation is wrong per se. When reactive messaging looks for a converter for a specific injection point, it picks the first converter that can convert. Note that converters are cabled separately on each injection point, depending on the target type of the injection point. It is very unlikely that the converter will change mid-consumption for a given channel-injection target pair.

Nevertheless I'll keep this PR separate from the MessageConverter's change.

[kdubb]

@ozangunalp The issue is the incoming messages changing. You cal canConvert on one instance and assume every instance to follow is exactly the same format.

The performance penalty to call canConvert first seems very negligible. Messages that are formatted identically will respond yes and no lookup happens.

[ozangunalp]

I understand that the penalty is negligible. I think MessageConverter was designed to adapt the message to the injection point type, rather than to parse the payload.

If you don't mind, I'd like to keep your contribution for RabbitMQ converters in #1772 but adapt it to roll back the IncomingMessageConverter change. The message will still be nack'ed if the conversion fails.

I've prepared another PR for improving message interceptors, including outgoing messages.

[cescoffier]

This PR should not touch the converter (and converters are cached by design).