Fixes: https://github.com/spring-cloud/spring-functions-catalog/issues/107
When we have a composition like this:
```
spring.cloud.function.definition = fileSupplier|splitterFunction
```
Then final "function" signature is like this `Supplier<Flux<Message<List<Message<?>>>>>`.
And that is exactly what we don't expected from the splitter in the end of the composition.
While Spring Cloud Stream supports de-batching, it works for a `List` output only if function is bound by itself.
In case of composition we got just a `Supplier`.
* Rework `SplitterFunctionConfiguration` for `splitterFunction` from `Function<Message<?>, List<Message<?>>>`
to `Function<Flux<Message<?>>, Flux<Message<?>>>` signature to support every possible simple and composed bindings
in Spring Cloud Stream
* Rework `SplitterFunctionApplicationTests` for new expected `Function<Flux<Message<?>>, Flux<Message<?>>>` signature
* Rework `zip-split-rabbit-binder` sample to not use a `flattenFunction` workaround
and fully rely on whatever is new for the `splitterFunction`
* Fix `ZipSplitRabbitBinderApplicationTests` moving the `@RabbitListener` into a `@TestConfiguration`.
Apparently in a new Spring Boot version the test class is registered as a bean much later than normal application context startup.
Therefore, even if the `@RabbitListener` parsed and registered properly, the `RabbitAdmin` bean
has been already started to see our extra bean definition for the `@QueueBinding`
Changing signature for the splitterFunction to reactive types would make it working even with a Supplier composition.
Fix JDBC & MongoDB suppliers to deal with a new version of Splitter function
Fix Checkstyle violations
Use `IntegrationReactiveUtils.messageSourceToFlux()` API
The `IntegrationReactiveUtils.messageSourceToFlux()` provides convenient API to represent a `MessageSource`
as a `Flux` to poll this source.
The API has an error handling logic and delay when no data emitted by the source
* Remove `org.springframework.cloud` dependencies from the project
since we don't use `@PollableBean` anymore, which comes from the `spring-cloud-function-context`
* Simplify `JdbcSupplierConfiguration` and `MongodbSupplierConfiguration` code more: more injections to the respective bean method.
* Use `(__) ->` lambda syntax for unused argument
* Remove unused `ThreadLocalFluxSinkMessageChannel` internal class
* Update Copyrights of the classes in this change
Upgrade to Gradle `8.12`
* Upgrade to the latest dependencies
* Remove wrong JMS dependencies from the `spring-twitter-supplier`: there is really nothing to do with JMS
* Fix `CassandraTestContainer` to use new `CassandraContainer` class version: essentially, a deprecation of the previous one has led here
* Remove `apicurio` dependencies from the `spring-debezium-autoconfigure`.
We really don't need them for our logic and if there is a requirement in the target project, they can add such a dependency manually.
* Remove `commons-compress`, `avro` & `json` dependencies from the `spring-debezium-supplier`,
since they are just transitive dependencies for not any managed `apicurio` dependency
* Add explicit version for the `com.squareup.okhttp3:mockwebserver` since Spring Boot does not manage this dependency anymore
* Use Hazelcast `5.4.0` version since managed by Spring Boot `5.5.0` has a CP subsystem as a commercial offering only
* `@MockBean` to `@MockitoBean` in the `AbstractAwsS3ConsumerMockTests` since the first one is deprecated in Spring Boot, in favor of the second one
* Fix `ZeroMqConsumerConfiguration` to start `ZeroMqMessageHandler` from the `Flux` of function input
* Upgrade samples to the latest dependencies
More info in: https://stackoverflow.com/questions/79250487/is-there-any-way-to-build-an-sftpsupplier-splitter-batch-producer-with-spring
* Address PR reviews:
* Fix typos and language in README
* Fix new line in the end of `application.yml`
* Move `@Bean` for `RabbitMQContainer` as a regular `static` property on the class with a `@Container`
* Use `@Testcontainers(disabledWithoutDocker = true)`
* Move `@RabbitListener` method directly to test class
* In the end we don't need extra `@TestConfiguration` class at all